Visual Studio Hacks [Electronic resources] نسخه متنی

Hack 65. Follow the Rules with FxCop

Determine whether your code and assemblies play
by the rules and guidelines.

A common problem in the realm of software
development is how to properly enforce coding standards and design
guidelines (this is especially true in large corporations where a
project team typically consists of several developers, each with his
own coding style). In the majority of projects, these issues are
addressed in a manual effort, occurring in the form of code reviews
and design reviews. While absolutely necessary, these types of
reviews often occur too late in the process; thus, problem areas
identified in those reviews might not always get the proper attention
they deserve.

To help alleviate these issues, Microsoft
developed a free code analysis tool named FxCop (http://www.gotdotnet.com/team/fxcop). FxCop
checks .NET assemblies for conformance to the
Microsoft .NET Framework Design
Guidelines (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp).
It uses reflection, MSIL parsing, and call graph analysis to inspect
assemblies for defects in the following areas:

Library design

Localization

Naming conventions

Performance

Security

Although primarily targeted at class library developers, FxCop can be
used on any managed code assembly, and it's
recommended that developers use it. FxCop includes both GUI and
command-line versions of the tool, as well as an SDK to create custom
rules.

An interesting aspect of using FxCop is that it can be used as a
learning tool, especially to design guidelines and best practices. So
even if you don't use FxCop to strictly enforce
certain guidelines, you can use it to at least gain insight as to why
the guidelines are in place and what they mean.

7.8.1. Create an FxCop Project

To use
FxCop (assuming
you've already downloaded and installed it),
you'll first need to create a project in Visual
Studio and compile that project; in this case, I've
created a class library project named MathLibrary. You can create an
FxCop Project by following these steps:

Start an instance of FxCop.

Click File Project Add Targets (Ctrl-Shift-A).

Browse to your .NET assembly, select it, and click Open.
You'll now see your assembly listed under the
Targets tab.

Click File Save Project (Ctrl-S).

In the Save As dialog box, type a name for your FxCop Project, select
a location, and click Save. Note that all FxCop Project files are
saved with an .fxcop extension; however, these
are just XML files that contain all the information needed for your
project.

7.8.2. Analyze Your Assemblies

Now
that you've
created and saved an FxCop Project, you can use it to analyze your
.NET assemblies for code and design conformance. To do this, click
Project Analyze (or press the F5 key).

Once FxCop has completed its analysis, you'll more
than likely see several messages appear in the righthand pane of the
tool, as shown in Figure 7-27.

Figure 7-27. An analyzed assembly with FxCop

There are a couple things to take note of in Figure 7-27. First, you can see that FxCop assigns a
certainty to each message. For instance, FxCop is 95% certain that
the class SimpleMath does not belong to a
namespace, therefore violating the rule "Declare
types in namespaces". Also note that FxCop tells you
exactly what item is in violation of a particular rule and gives each
item a Fix Category, such as Breaking or Non Breaking.

You can view a summary of the analysis by clicking Project
Analysis Summary. This will show you how long the analysis took to
execute, the number of checks performed, and how many issues were
found. The summary for the MathLibrary assembly is shown in Figure 7-28.

Figure 7-28. Analysis Summary

You can view even more details of a particular message by selecting
it from the list. For this example, let's
investigate further the message with the rule violation
"Identifiers should be cased
correctly", shown in Figure 7-29.

Figure 7-29. Properties tab for a given issue in FxCap

The Properties tab displays information that
is much more useful to you. Here you can see that the
Add method in the SimpleMath
class contains a parameter named Expression1,
which is PascalCased, and the guidelines say parameters should be
camelCased. You also see the suggested resolution as well as the
source of the rule violation. The source of the rule violation is
shown in the Location line, which shows the file and line of code in
violation (C:/MathLibrary/SimpleMath.cs, line 12
in this example).

The Properties tab also shows you where to find help for the
violation and the rule file used in the analysis. When I mentioned
earlier that FxCop is a good learning tool, it was because of the
information provided in this tab. As you can see, the tool provides
insight as to why the message was generated.

7.8.3. Fix a Messageand Watch It Disappear

Great, you've written a
class library that you think is rock solid, but then you run FxCop on
it, which generates more issues than you care to admit. Chances are
you'll choose to ignore some messages (for various
reasons), but you'll want to take care of others.
The good news is that FxCop identifies exactly where the issues are,
so most of the work of tracking down the violations has already been
done for you. All you have to do is fix the problem and recompile
your assembly.

Previous versions of FxCop would keep a lock on the .NET assembly you
were trying to analyze; thus, when you went to modify your code and
recompile the assembly with FxCop still open, you would get an Access
Denied error. To get around this, you had to shut down FxCop,
recompile your code, then open FxCop again. Luckily, Version 1.30 and
above of FxCop fixed this major annoyance, so you can continuously
run Visual Studio and FxCop side by side.

To see your number of FxCop messages decrease, make the necessary
code changes in Visual Studio, recompile, then flip back over to
FxCop and hit the F5 key to reanalyze your assembly. In our example,
I'm going to fix two messages:
"Declare types in namespaces" and
"Identifiers should be cased
correctly". After fixing these two issues, my FxCop
results look like Figure 7-30.

Figure 7-30. FxCop results after code fixes

7.8.4. A Look at the Rules

Now that you've seen how to use FxCop and what it's
good for, you must be wondering where all those rules are and whether you really
need to analyze all your assemblies against every single rule FxCop
has. The answer is no. Although that is strongly suggested, the FxCop
team understands that not everyone can abide by all the rules set
forth in the .NET Framework Design Guidelines all the time.
Therefore, they've made it very easy to pick and
choose which rules will be used in the analysis of your .NET
assemblies. By default, all rules are used during the analysis, but
that can be easily changed.

To see the rules, click the Rules tab in the left pane of FxCop. You
will see Figure 7-31.

Figure 7-31. FxCop rules

Notice that all rules are expandable and can be checked or unchecked
as needed. For instance, if you choose to ignore all interoperability
rules, you would simply uncheck the Interoperability Rules box. If
you did so, your rules selection would now look like Figure 7-32.

Figure 7-32. FxCop rules with Interoperability Rules ignored

It's clearly visible in Figure 7-32
that each set of rules contains several individual rules that can
also be selected or unselected as required for your project.
I'll leave the exploration of the other sets of
rules up to you, but it's easy to see that FxCop
allows you to customize your code and design analysis as you see fit.

Another item of note about the Rules view is that you can begin to
see how your rules violations are categorized. For example, if you
wanted to know how many of your overall number of messages were based
on design issues, you would switch to the Rules view and select
Design Rules, as shown in Figure 7-33. This view
shows that five messages of my overall issues were generated from the
design rules.

Figure 7-33. Messages specific for design rules

7.8.5. Visual Studio Integration

Up to this point, I've
demonstrated the preferred way of using FxCop. However, FxCop
provides a command-line interface that can be used from within Visual
Studio.

The first thing that you must do is to set up FxCop as
an external tool in Visual Studio
[Hack #33] . To do this:

Start an instance of Visual Studio.

Click File Tools External Tools Add.

In the Title box, enter FxCop.

In the Command box, enter C:\Program
Files\Microsoft FxCop
1.312\FxCopCmd.exe. (The actual
path will vary based on the version of FxCop and where you installed
it.)

In the Arguments box, enter:

/c /f:$(TargetPath) /r:"C:\Program Files\
Microsoft FxCop 1.312
\Rules"

You can leave the Initial Directory box empty.

Check the Use Output Window box. Then click OK.

Click File Tools, and verify that you now see FxCop as an
option.

Figure 7-34 shows a completed External Tools dialog.

Figure 7-34. Completed dialog for adding FxCop as an external tool

Now that FxCop is set up as an external tool in Visual Studio, you
can run FxCop on your .NET assemblies very easily:

Open a Visual Studio Project.

Click Tools FxCop.

The Output window will appear and show the results of the analysis (see Figure 7-35).

Figure 7-35. Output window showing FxCop analysis

7.8.6. More FxCop Resources

The goal of this hack is to expose you
to when, why, and how you would use FxCop. However, there is much
more to FxCop that cannot be covered in detail here, such as the
ability to create your own rules. Here are additional FxCop
resources:

You can find out much more about the tool and how to best use it by
reading its built-in
help functionality.

In addition to more
documentation, here you can find the latest downloads, readme files,
and samples. You can also find custom rules that other developers
have created for use in your own FxCop Projects.

Although
not
updated very often, this site does provide some good information.

John Robbins wrote two excellent articles about FxCop for the June
and September 2004 issues of MSDN Magazine.
These are highly recommended reads.

Dave Donaldson