In this version, we’re telling FxCop command line tool to use a custom dictionary - more on this later,
the project file we created earlier, and to output the results to an XML file.

When being run, FxCop tends to load the previous results, which would cause load errors if we renamed classes that previously had errors,
so we’ll <Delete/> the output file before running the task.

The nicer, more explicit way, has us use the supplemental tasks provided by the MSBuild Community Tasks Project,
in particular the <FxCop/> task (grab at least version 1.3.0.528, part of the nightly builds - v1.2 doesn’t
properly support this task).

What you won’t find in the MSBuild Community Tasks documentation is the requirement to use the ToolPath to point to the right version
of FxCop. As of now, the <FxCop/> task looks explicitly for FxCop v1.32 and for a registry key that no longer exists
when it tries to build the full command line:

...if(string.IsNullOrEmpty(ToolPath)){stringfxCopPath=Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles);fxCopPath=Path.Combine(fxCopPath,@"Microsoft FxCop 1.32");try{using(RegistryKeybuildKey=Registry.ClassesRoot.OpenSubKey(@"FxCopProject\shell\Open\command")){if(buildKey==null){Log.LogError("Could not find the FxCopProject File command in the registry. Please make sure FxCop is installed.");}else{fxCopPath=buildKey.GetValue(null,fxCopPath).ToString();...

The problem with the registry look up is that FxCop v1.36 uses a key called FxCop.Project.9.0,
all which means that the <FxCop/> task fails to find the executable. That is why we have to use the
ToolPath, inherited from its Task parent, to help it find it.

Alright, now the promised dictionary clarification.

If our namespaces, classes, etc. include non-lexical words, for example Flickr.Configurator, FxCop will announce
that our code breaks a naming rule - CA1704:IdentifiersShouldBeSpelledCorrectly - and will tell us to:

Correct the spelling of ‘Flickr’ in assembly ExternalDependencies.dll’.

Correct the spelling of ‘Configurator’ in assembly ExternalDependencies.dll’.

(Yes, Configurator is not an English word either - us developers have a lot of those.)

We’ll then spell this dictionary using the CustomDictionary property of the <FxCop/> task.

We could and should also add the dictionary into the FxCop project file to make sure the GUI doesn’t complain
about those naming rules being broken either. Find the <CustomDictionaries/> node within the project file,
Default.FxCop in the examples above, and add a <CustomDictionary/> node:

<CustomDictionariesSearchFxCopDir="True"SearchUserProfile="True"SearchProjectDir="True"><!-- Tells FxCop to find it in the same location as the Default.FxCop file --><CustomDictionaryPath="CodeAnalysisDictionary.xml"/></CustomDictionaries>

CCNet captures all the output of a build into a giant result file using <merge> tasks.
We’ll follow the instructions on the CCNet website to merge in the generated fxcop.xml file:

<tasks><merge><files><file>fxcop.xml</file><!-- Other files to merge for your build would also be included here --></files></merge></tasks>

Finally, to be able view the results of the FxCop analysis in CCNet’s web dashboard, we’ll need to include
the XSLT files, which extract and pretty up the entries merged in from fxcop.xml, into
the dashboard.config file, typically located within C:\Program Files\CruiseControl.NET\webdashboard\ folder:

...
<buildPlugins><buildReportBuildPlugin><xslFileNames><!-- other xsl file, such nunit and msbuild --><xslFile>xsl\fxcop-summary_1_36.xsl</xslFile><xslFile>xsl\fxcop-report_1_36.xsl</xslFile></xslFileNames></buildReportBuildPlugin><buildLogBuildPlugin/><!-- These create two menu entries on the left, when viewing a project's build page --><xslReportBuildPlugindescription="FxCop Summary"actionName="FxCopSummary"xslFileName="xsl\fxcop-summary_1_36.xsl"></xslReportBuildPlugin><xslReportBuildPlugindescription="FxCop Report"actionName="FxCopReport"xslFileName="xsl\fxcop-report_1_36.xsl"></xslReportBuildPlugin></buildPlugins>

That’s it. Next time you build you should see the FxCop details when you click the “FxCop Report” link.

The only one thing to note is that violating FxCop rules, no matter their level or the value of ContinueOnError,
will not mark the build a broken. If you want FxCop failures to break the build, there is
one further step you need to take.

So? Liked it? Hated it? Thought it was stupid? Thought I was stupid? Deemed it to be informative? Want to lavish excessive praise or cast fiery insults? Contact me and have at it.