Atmosera

Initially Turning on FxCop/Code Analysis for a Large Code Base

Recently I was asked a question that’s come up several times so I thought I’d share the answer.

I’ve inherited a large code base that has never had FxCop run on it. When I ran the binaries through FxCop, it reported tens of thousands of warnings, which overwhelmed me. While I should fix those warnings, how do I separate the warnings so I focus on the most important and get the process started? My boss is saying to forget FxCop as we don’t have the time to fix all those warnings but I want to justify using FxCop.

FxCop is a fantastic tool and one I highly recommend using on every single compile that anyone does. It catches all sorts of .NET coding errors and ensures you are following the .NET Framework Design Guidelines. As I read many years ago in a compiler manual, “Never do anything at run time you can do at compile time.”

Sadly, as my questioner points out, if you’re on a team that has never used FxCop, that first run can almost be the last run of the tool ever made across the code. As I’ve been in the exact situation on several teams, here’s what I did to start getting FxCop integrated into the builds and provide a path to working towards 100% FxCop clean reports.

If you’re on a team where you’re using Visual Studio Team Developer Edition or higher, you’ve got FxCop built into the IDE and its called Code Analysis. If you’re using Visual Studio Professional Edition or lower, you can install the standalone FxCop and integrate it into your builds by following the instructions on the FxCop team blog.

The first set of rules where you are going to see many errors is the Globalization set of rules. You will want to fix these rules if you have plan to make any money from the rest of the world with your software, but if you’ve never run FxCop nearly all your string operations locations will be reported as having a problem. While you can disable all the Globalization rules, the two in particular that will cause the most warnings are CA1304 Specify CultureInfo and CA1305 Specify IFormatProvider.

The biggest set of errors will come out of the Naming set of rules. These rules enforce a consistent naming and punctuation scheme across methods, classes, and properties. That’s fantastic for readability and I love those rules, but for those large code bases, turning off the entire category will help you focus on the more serious rules.

I hope that these ideas will motivate you to start using FxCop on your code if you’re not. FxCop turns up all sorts of nasty bugs in your code with no effort on your part. All it takes is a single report of CA1404 Call GetLastError Immediately after P/Invoke to have any effort you put into using FxCop completely pay for itself. What I’ve talked about here is for that first run on a code base. It goes without saying that any new code must be run with all FxCop rules turned on so the cost of fixing them is trivial.

John Robbins

Next Silverlight Behaviors and Triggers: TextBox Magic »

Previous « Silverlight Behaviors and Triggers: Storyboard Trigger Example

View Comments

Anonymous says:

October 6, 2009 at 9:43 pm

I'll add that running code analysis on both debug and release builds help keep that error list short. I'm a fan having been saved by that "mini code review" more than once.
jrobbins says:

October 6, 2009 at 9:49 pm

Don,
Absolutely! I didn't make that as clear as I should: EVERY BUILD MUST HAVE FXCOP RUN ON THEM! How's that?
- John Robbins
Anonymous says:

October 7, 2009 at 5:01 am

I think I have a small improvement to suggest on the FxCop team instructions; how to break the build if any FxCop warnings occur. Obviously not useful if you're in the positon of your questioner, but much more useful if you're working with new code and have Visual Studio Professional Edition or lower.
If you want more fine control over FxCop's behaviour, then John Rayner has a post that may help.
jrobbins says:

October 7, 2009 at 7:33 pm

Gavin,
Absolutely, I agree that FxCop warnings need to be build breaks! Thanks for the two links as they are great tricks to get FxCop working as part of your build. Thanks a million for sharing them.
- John Robbins
Anonymous says:

October 19, 2009 at 12:26 pm

Code Analysis is one of those great tools that people don't run nearly enough. I have screamed repeatedly,
Anonymous says:

January 18, 2010 at 2:16 am

I am using FxCop1.36 with VS2005 during Post Build event. I am passing Post-build event command like the one which I have displayed below..
copy /y "$(TargetPath)" "C:eComObjects"
cd "$(ProjectDir)......ScriptsFxCopScripts"
"runfxcop.cmd" "$(TargetPath)"
Actually my intention is as per the requirement I'll have to ignore some namespaces and/or rules...How can I do that using the above command..The specified command is working fine right now...Could someone help me out regarding the same.
How to ignore autogenerated code like the code which got generated by VSDesigner, WSDL and etc.,
Anonymous says:

February 4, 2010 at 9:24 pm

This post just saved me a bunch of work by linking to the Code Analysis archive about running FxCop during a post build event! Thanks John!
jrobbins says:

March 11, 2010 at 12:03 am

VenkatDuvvuri,
If you're using the standalone FxCop, you can use a project file to suppress errors in sections you don't want to see.
David Smith,
Very glad to help! :)
- John Robbins