Analyze your managed .NET code with FxCop

by Tony Patton | Jan 23, 2007 9:32:00 PM

Tags: .NET, Application servers, Middleware, Tony Patton, FxCop, Microsoft .NET, .NET Newsletter

Takeaway: Check your .NET code for bugs and compare it against Microsoft's design guidelines via the freely available FxCop. Learn more about this code analysis tool in this week's .NET column.

I have never met a programmer who doesn't make a coding mistake from time to time. Tracking down and addressing these issues can be one of the most important aspects of your job. The next time you need to analyze your managed .NET code, I recommend using Microsoft's FxCop tool to track down bugs.

What is FxCop?

FxCop is a code analysis tool that checks managed code assemblies for conformance to Microsoft .NET Framework design guidelines. It uses a rule-based engine to check your code against the guidelines; you can also add your own rules to the engine. The tool is freely available from Microsoft. The most recent version works with .NET 2.0; there's also an older version available for .NET 1.1.

The latest version of FxCop uses a technique called introspection to take a peek inside your assemblies (previous versions used reflection). This is notable because previous versions required you to stop and restart when any changes were made to your code; this is no longer necessary with the new version.

Most code analysis tools scan your source code, but FxCop works with your compiled code. Every assembly in .NET has metadata, which describes the assembly and all types used in the assembly. FxCop uses this metadata to learn what is going on in the code. In addition, it examines the Microsoft Intermediate Language (MSIL) generated when code is compiled.

The combination of examining the metadata and MSIL provides FxCop plenty of information to gain an understanding of what the code is doing. It compares your code against the rules and generates a message for every instance where code doesn't conform to the rules.

Deciphering FxCop's messages

You can run FxCop once you download and install it. FxCop utilizes a simple Windows interface, which includes the following three panes (when first opened):

• Configuration (left side): This is where you define the assemblies to be analyzed and the rules used during analysis via two tabs labeled Target and Rules. FxCop calls the assemblies, resources, namespaces, or types to be analyzed as the Target. The Rules are applied to the Target.
• Message (right side): The results of the analysis (triggered via the Analyze button in the toolbar) are displayed in the Message pane. The messages are basically the list of improvements FxCop recommends to make to your code/assembly.
• Properties (bottom of the screen): This includes tabs labeled Output and Properties. Output shows informational, warning, and error messages generated by the rules. Properties shows information about the selected assembly, namespace, type, type member, group of rules, rule, or message.

The Message pane is the most important part of the FxCop interface since it provides information about what needs to be improved. After all, that is why you are using the FxCop tool in the first place.

The messages generated by the FxCop tool include the following five columns (you can add or remove columns in the tool):

• Level: FxCop assigns a level of importance to each issue. The levels are Critical Error, Error, Critical Warning, Warning, and Informational. The Critical Error level is the most severe since it says the corresponding code does not operate correctly in most situations. The Informational level is the least worrisome since it only includes information about the code.
• Fix Category: This is assigned to the message by FxCop. Two of the values it may include are Breaking (i.e., it breaks the code and doesn't do what it is supposed to do) and Not Breaking.
• Certainty: This is the percentage value that FxCop believes the item is an issue. That is, some messages are not problems after you review and analyze the questionable code, so FxCop assigns a percentage value to items to let you know how certain it is that something is really a problem.
• Rule: The rule name that generated the message.
• Item: The target item that generated the message.

For more information about a message, you can double-click it to see the complete message. This includes: the details of the rule it violates; the specific code line that violates the rule along with a link to more information on the rule (online), and more.

An example of what to expect from FxCop

Let's say you have a simple C# Windows application that creates an array and displays it contents. Listing A shows how FxCop will analyze the application. The snippet in Listing B shows one of the messages generated when the code's assembly is loaded in FxCop.

A quick review of this Critical Level message shows it is not critical to code execution—it is related to rolling out the application to users (Microsoft suggests the assembly should have a strong name and be signed).

This is a simple example, but you can gain a better understanding of FxCop by loading the application and putting it to use. Another good feature of FxCop is that it allows you to save messages as a report, which FxCop formats as XML.

What analysis tool do you use?

Do you use FxCop or a comparable tool to evaluate your .NET code? Please talk about your favorite code analysis tool in the article discussion.

Miss a column?

Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

Print/View all Posts Comments on this article

"Fix Category" explanation wrong jwhite@... | 01/29/07

"Fix Category" explanation wrong edollete@... | 02/05/07