Writing an FxCop Task for MSBuild

The source code to the FxCop task is provided here.

I've been working on improving our processes on the ASP.NET MVC team, and one of the things that we wanted to do was have our continuous integration build run FxCop.

Unlike most of the teams inside of the Developer Division, we're actually building ASP.NET MVC on the released versions of Visual Studio. The division has a ton of custom-built tooling, but since we don't live in the same space as they do, we're using the same tools and techniques that you guys use.

When I discovered that FxCop failures don't break the build by default, I went a-Bing'in to find the answer. What I found was several blog posts like this one from Ade Miller that described post-processing the XML file with a custom task to determine if they should fail the build. I think we could do better. I wanted our FxCop failures to feel just like standard build failures, not like afterthoughts with custom reports.

I'm no stranger to writing MSBuild plugins, so I decided it would be worth a few hours to write a task which not only ran FxCop, but parsed the resulting XML and turned it into MSBuild-style warnings and failures as appropriate.

This task does not provide 100% coverage of all the FxCop command line options: it's just enough to do what we need. You could use this task as a launching point in case you are using some FxCop options that we don't require, though I suspect we've easily covered the 90% cases here.

This is what the output looks like in our CCnet server:

Obviously, the new FxCop in VS 2010 brought us all kinds of things to find and fix. :)

One problem with an MSBuild-based FxCop task is that you'll need to make a new configuration for FxCop which defines the CODE_ANALYSIS symbol. You don't normally want this in your Debug/Release builds, because then all the FxCop exclusion attributes will show up in the binaries. So I created a third configuration, along side Debug and Release, and re-build the binaries I'm intended to test. I copy the Release configuration, because we run everything against our Release builds. You can see an example of this in the FxCopTask project (just peek inside the .csproj file, and you'll see the extra Configuration entry with its custom build location and definition of CODE_ANALYSIS).

Here is a sample MSBuild file that uses the task (here I'm using FxCopTask to test FxCopTask, and I purposefully left all the errors in it so you can see the results):

<Project DefaultTargets="FxCop" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <UsingTask
        AssemblyFile="bin\Debug\FxCopTask.dll"
        TaskName="FxCop"/>

    <Target Name="FxCop">
        <MSBuild
            Projects="FxCopTask.csproj"
            Targets="Build"
            Properties="Configuration=FxCop"/>
        <FxCop
            Assemblies="bin\FxCop\FxCopTask.dll"/>
    </Target>

</Project>

The only required property of the FxCop task is the Assemblies property (which can accept multiple assemblies). You can also specify which ruleset to run, where to load the rulesets from, whether you should fail on errors and/or warnings, where to find the FxCopCmd.exe file, which custom dictionary to use, and where to dump the XML file FxCop produces. The task automatically locates FxCop and the ruleset directory on machines with Visual Studio 2010 installed (if FxCop is installed). Just take a look inside of FxCop.cs to see what properties are available, and what their default values are.

Enjoy!