Home


Sample FxCop rules

So far, there's only one sample rule available: JustifyRuleViolationSuppressions. If you would simply like to use the rule, download the compiled library then place the extracted DLL in the Rules subdirectory of your Visual Studio 2005 static analysis directory (usually C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules\).

If you're curious about how the rule was created, you'll probably be more interested in the library source code and the explanations below. If you do decide to download the source code, please note that you will also need msxsl.exe, which can be downloaded from the Microsoft Download Centre, should you wish to be able to build the project as-is. If you do download it, copy the msxsl.exe file to the RuleDocumentation subfolder in the library project directory.

In addition, if you do attempt to work with the sample rule project, you'll notice that it's configured to work with stand-alone FxCop rather than Visual Studio 2005 static analysis. While the sample rule isn't likely to be terribly useful for most folks that use stand-alone FxCop, it's quite a bit quicker to perform initial rule debugging with stand-alone FxCop, which is why I left the project configured that way.

For successful compilation, there are a couple of other details to look after:

  1. The strong name signing details have been removed from the project configuration. To avoid compile-time errors in an edition of Visual Studio 2005 that supports static analysis, you'll either need to specify your own strong name signing configuration (see the MSDN "how to" on assembly signing for details) or change the project settings so that violations of the Design.AssembliesShouldHaveValidStrongNames rule are not treated as errors.
  2. In order to facilitate rule testing, a post-build event automatically copies the built assembly to the FxCop rules directory. You might need to change the target path (along with the path of the referenced FxCop libraries), which is a minor detail. Of somewhat greater concern is that the file copy will not work if you are running Visual Studio as a non-administrator. Personally, I usually run one instance of Visual Studio as a administrator while developing FxCop rules in order to avoid manual file copying under elevate permissions, but I do take care to ensure that any FxCop or Visual Studio instances that are used for testing the rules under development are run with a non-admin account. If you would prefer not to run Visual Studio as an admin while developing FxCop rules, you'll probably want to remove the post-build event.

Once you've got the project set up, you may wish to take a look at the detailed documentation for an explanation of how the custom rule was created.



If you're looking for my FxCop presentation from the Montreal Visual Studio User Group, you can download it here. However, before you do so, you might want consider that it's in French, and it's 1.5M. Just a little warning...