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.

Weekly .NET tips in your inbox

TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET.

Automatically sign up today!

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.