November 26, 2003

DevPartner 7.1 is a powerful programmers suite

Compuware’s debugging, analysis, and profiling tool provides deep insight into .Net and Win32 code

The transition to Microsoft’s brave new world of managed code will probably take a decade, during which time Windows programmers will struggle with the complexities of a hybrid managed/unmanaged environment -- both in the Windows OS itself and in the componentized applications and services layered on top of it. Instrumenting these very different programming environments -- so that developers can analyze, profile, and more effectively debug programs straddling the unmanaged and managed worlds -- is a big challenge that Compuware's latest offering, DevPartner Studio 7.1, tackles fearlessly.

The DevPartner suite, which integrates deeply and gracefully with Visual Studio .Net 2002 or 2003 (I tested with both versions of the integrated development environment), supports the following activities in addition to run-time error detection: source-code review, code coverage analysis, memory analysis, profiling, and analysis of distributed applications. To perform one of these activities, select it on the VS .Net toolbar, optionally adjust the instrumentation that DevPartner will insert (in the case of unmanaged code), then debug (or in some cases just run) the application, and analyze results in the VS .Net document pane. Resulting data files accumulate, by activity type, in DevPartner’s Solution Explorer.

To exercise the suite, I worked with open source indexing and search engine NLucene, which is a C# port of the popular Java-based engine, Lucene. I used DevPartner Studio to analyze the NLucene library, to analyze a program that indexes a batch of HTML files, and finally to analyze an ASP .Net application that searches that index.

Reviewing the Source

The source-code review feature, available for C#, VB .Net, and VB6, scanned the C# files and produced a report that was sometimes pedantic, and sometimes cogent and educational. Warnings about recursion, hard-coded strings, or member-variable names fall into the pedantic category. I assume developers are grown-ups who understand the consequences of these choices. Much more interesting are warnings that teach developers about platform subtleties. The warning ("Type not excluded from use by untrusted code") falls into this latter category. When an assembly is unsigned, as my build of NLucene was, you can still enforce trusted access by adding appropriate attributes to the source code. DevPartner identified the problem and illustrated the fix -- a nice example of how an intelligent automated assistant can work with a developer to improve code quality.

Some of the rules that drive code review are hard-coded into DevPartner, but others are available for inspection and modification in a rules editor. A shop that wants to enforce its own naming conventions, or classify new coding idioms, can do so. Compuware could, and arguably should, host a service for developers who would like to collaboratively define and share such patterns. The .Net CodeDOM, which, as the name implies, is a document object model for parsed code, suggests another intriguing possibility. Currently DevPartner's rules editor relies on regular expressions to define the patterns that trigger warnings. In theory, CodeDOM will enable higher-order pattern recognition that's also independent of the source language. I'll be interested to see if a future DevPartner release exploits that opportunity.

Analysis From All Sides

Test Center Scorecard
30%30%30%10%
DevPartner Studio Professional Edition 7.17998
8.3
Very Good

Sign up to receive InfoWorld Resource Alerts

Subscribe to the Developer World Newsletter

The one-stop resource center for IT professionals.

©1994-2009 Infoworld, Inc.