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.