Debugging .Net enterprise code is a daunting task for corporate developers because Visual Studio and .Net hide complexity quite well. Even with all the debugging power behind Visual Studio 2005, developers still need simple run-time debugging tools that can trace .Net's memory. Compuware's DevPartner Studio 8.0 is ideal for testing .Net applications.

DevPartner, which fully integrates with Visual Studio 2005, uses a database of more than 600 rules from best practices that Compuware has accumulated for .Net applications. The static code analysis is extremely simple. After parsing .Net code, DevPartner compares it with all known problems in its database and returns a list of rules that were broken in the code.

Each rule provides an explanation section, a source line, what triggered the error, a repair section, and a notes section. The repair section shows that sample code can be written in either C#, Visual Basic .Net, or C++. The errors correlate with parsed code.

(click image for larger view) Find the cause of performance bottlenecks.

Developers can change DevPartner configurations so it only detects certain errors that are implementation-specific such as .Net, Component Object Model, and Win32 API. Repair sections in a feature known as Code Review will display either managed code or Win32 code, depending on the error found. In addition to scanning code, Code Review can be programmed to analyze object and variable declarations to make sure code follows company-accepted naming conventions, including specific coding standards used by the industry such as Pascal or Hungarian notation.

During run-time analysis, DevPartner provides a real-time graph of memory use. The graph explores .Net's memory manager, which runs the garbage collector. The analysis is dynamic, so developers can inspect memory as they traverse an application by clicking on buttons or just navigate through HTML pages. The memory graph also identifies how temporary objects in an application are using the .Net heap. DevPartner can identify memory leaks by performing memory leak checks in specific regions holding allocated objects that may be dangling without being picked up by .Net's garbage collector.

Memory Aid

DevPartner can force multiple garbage-collecting instances that allow developers to compare a baseline memory with a current memory execution. The comparison can point out objects that were allocated but not collected. The software also can point to the line of code that created a leak. The memory detection checks .Net's stack, which holds pointers to objects and variable addresses. This feature can save .Net developers dozens of hours trying to capture memory-based exceptions using all sorts of kludgy techniques. Because .Net hides so much code, memory leaks are one of the most difficult things to identify.