Change FXCop Cyclomatic Complexity Threshold Values

Update: Here's the 2008 Version, the below post is for Visual Studio 2005.


Glavs Blog has provided light at the end of the tunnel for those of us who have been scouring the Internet for a way to change Visual Studio Code Analysis Cyclomatic Complexity thresholds. The shipped thresholds are way to high for my taste and I've wanted an easy way to integrate an enforced cyclomatic complexity ceiling within the red-green-refactor process. Glavs article about Creating Custom FXCop rules and altering existing ones - Part 2 shows how to use the .Net framework utilities Ildasm.exe and ILasm.exe to pipe out the contents of the code analysis rule to MSIL, change it and then recompile with the changes. Following this procedure the shipped CC thresholds of warning at 25, critical warning at 50, error at 75 and critical error at 100 can now be whatever you desire.

I suggest one alteration to Glavs directions; don't' recompile to the same assembly name. This will cause other code, such as the Code Analysis Check-In Policy, that was compiled against the Microsoft shipped strong name version to break, and any service packs that ship a new version of the assembly will overwrite your changes. So compile it to a new name leave it in the same folder then in your VS.Net projects enable the new code analysis rule and disable the old.

Of course, I don't know the legal or ethic responsibilities of Monkey Patching the code analysis rule under the Visual Studio license. Hopefully Microsoft will understand that this is an attempt to get the best value out of the IDE when other options aren't available and not an attempt to gain a competitive advantage or tarnish their product.