How to fail TFS build based on FXCop warning

Question

We are currently using TFS 2008 for source control and continuous integration.

We use FXCop to check for checking performance and security warnings. The Architect or senior developer runs FX Cop at the end of a sprint or before a delivery.

We would like this to run as part of the CI and fail the build if there is a warning, what is the best way to do this?

Answer 1

You could take a look at the code analysis features within Visual Studio, which is supported for use in a continuous integration environment.

Answer 2

I've been working on something similar. Even though this question is a bit old, I'm hoping it will help you.

I started out like most -- by making a post-build event that calls FxCopCmd.

In my case, I wanted just a small subset of the code, some of the built-in rules, and also some custom rules (in a .dll)

I used an .fxcop project file for this -- configuring it all just how I wanted via the GUI and then pointing FxCopCmd to the project file in the post-build event.

For the most part, it worked great, but the rule violations came up only as warnings. The "Treat warnings as errors" option doesn't seem to apply to this, so I had to come up with a different solution.

What ultimately worked best for me was based on a blog post I stumbled upon.

I modified the project file to add in two new events.

I have a few extra parameters and stuff for FxCop, but the gist of it is:

   1: <PropertyGroup>
   2:   <FxCopResults>$(ProjectDir)obj\$(Configuration)\FxCopResults.xml</FxCopResults>
   3:   <PostBuildEvent>"%25ProgramFiles%25\Microsoft FxCop 10.0\FxCopCmd.exe" /file:"$(TargetPath)" /console /out:"$(ProjectDir)obj\$(ConfigurationName)\FxCopResults.xml"</PostBuildEvent>
   4: </PropertyGroup>
   5: <Target Name="BeforeBuild">
   6:   <Delete Files="$(FxCopResults)" ContinueOnError="true" />
   7: </Target>
   8: <Target Name="AfterBuild">
   9:   <Error Text="One or more FxCop warnings occurred." Condition="Exists('$(FxCopResults)')" />
  10: </Target>

The general flow is like this:

1. (BUILD PROCESS IS TRIGGERED)
2. Before a build starts, the previous FxCop results (if they exist) are cleared out.
3. Pre-Build Event is triggered
4. (BUILD BEGINS)
5. Post-Build Event is triggered (which runs FxCopCmd)
6. After the Post-Build finishes, if there are FxCop results, an error is raised.
7. (BUILD PROCESS IS COMPLETE)

Now, if the FxCop analysis generated -- for example -- 4 rule violations, your build would generate 4 warnings and 1 error.

I hope this helps.

Answer 3

Assuming you're building through MSBuild and regular projects/solutions, you can configure FXCop to run as part of every build (both client and server). In your project's properties dialogue, look at the "Code Analysis" tab. Note that this can be set separately for debug and release builds, so you could just set them to errors for Release builds if that makes your developers' life easier.

These FXCop settings allow you to define that violations appear as errors instead of warnings in the build. You mkight also want to enable the TFS policy that requires code analysis to have been run with a defined set of rules before the checkin is valid - that'll save you some red builds by forcing developers to fix violations before checkin.

I do recommend turning all of these things on - if you're aiming for this level of quality (which is no bad idea), it's good to be doing as much as you can pre-checkin.