photo credit: Thomas Hawk
This is a second post on my “guidelines” series. Some information here is specific to the projects I’m working on, and some is more general and so applicable to any project.
FxCop is a free static source code analysis tool created by Microsoft. It analyses your built assemblies and reports any issues it encounters. It has a set of rules (which can be turned on/off) which it uses to detect these issues. FxCop comes both in the command-line form (FxCopCmd) and as a Windows GUI.
Building
The general approach in our build scripts is: the script compiles the code and then immediately runs the FxCop analysis. If it detects any issues, it automatically runs the GUI and opens the relevant FxCop project. NOTE: you need to press F5 key (rebuild project) in order for FxCop to show the latest results!
When run “headless” (on the build server), the script of course doesn’t open the GUI – it just simply fails and then kindly informs the offender via email.
Resolving Issues
There are basically three ways how to resolve issues detected by FxCop, described in the following subsections.
Fixing The Code
Fixing the code where the issue has been detected is the preferred approach.
Applying Suppression Attribute On The Code
SuppressMessageAttribute can be used to suppress reporting of a specific defect by FxCop:
[SuppressMessage("Microsoft.Performance", "CA1822:MarkMembersAsStatic")]
You can autogenerate these suppress lines by right-clicking on the issue, selecting Copy As -> Suppress Message. This will copy the suppress attribute into the clipboard and you can then paste it into the offending code. Depending on the type of the issue, the code has to be copied either in front of a class/interface, method, property or a field.
You should only suppress issues which you think
- aren’t really issues
- aren’t relevant
- the offending code has been designed on purpose.
On all other occasions, it is better to fix the code.
Excluding Issues In FxCop GUI
Sometimes (in rare situations) it is difficult to suppress an issue. In that case you can exclude them in the FxCop GUI by right clicking on the issue(s) and selecting Exclude.
NOTE: if you do any excluding in the GUI, don’t forget to save the FxCop project before exiting!
Language Issues
Since FxCop checks the spelling of class, method and other names in the source code, some FxCop issues are related to English dictionary. For example, on the latest project I’m working on, FxCop reported a spelling error for classes containing the MVC string, since MVC “word” isn’t in the standard English dictionary.
This can be resolved by adding such words in the CustomDictionary.xml file which is stored in the root directory of the project’s solution:
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
<Words>
...
<Recognized>
...
<Word>mvc</Word>
...
</Recognized>
...
</Words>
...
</Dictionary>Adding FxCop Analysis On New VS Projects
When creating new projects in the solution, you have to do two things:
- Add the CODE_ANALYSIS compilation symbol in the project (using VisualStudio). Don’t forget to add it both for Debug and Release configurations. Without this symbol, FxCop will ignore any of your Suppress attributes in the code.
- Add the project to the FxCop project file, example:
<Target Name="$(ProjectDir)/MyTool/bin/MyTool.dll" Analyze="True" AnalyzeAllChildren="True" />
In general, I tend not to add FxCop analysis for unit test projects because unit test classes usually violate certain rules on purpose (or by design). One example is having test methods which don’t reference class instance stuff, for which FxCop reports the “mark member as static” issue.
Finally
There are some other minor “quirks” which can occur, I’ll try to add additional guidance if/when my team members encounter them 
.
) was dedicated to Kosmos. Which reminded me that I should probably update the Kosmos screenshot on the OSM Wiki page with some new and more interesting stuff.
