Pulled Apart - Part X: Visual Studio Rulesets
[
]
Note: This is part of a series. You can find the rest of the parts in the series index.
Microsoft has offered a great tool called fxCop for a number of years now. This free tool takes your compiled .NET code and runs it against a number of rules to check things like security, compatibility, globalization, and so on.

Some of the higher SKUs of Visual Studio have included fxCop directly in the IDE via the Code Analysis option. In previous versions of Visual Studio, this just ran the fxCop command line and returned the results. There was not much else happening except a shortcut to having to run a separate tool.
In Visual Studio 2010, the fxCop integration had a major improvement: the addition of a dedicated interface for managing which rules to run and the ability to create a bespoke collection of the rules you care about by ignoring the ones you don’t. The other great feature is that you can set whether a rule throws a warning or an error in Visual Studio—very useful for enforcing rules!

For Pull, I took the opportunity to create a dedicated rule set.
Step One – Theft
The first thing I did was to take the Microsoft All Rules rule set and copy it to my project, renaming it to pull.ruleset. You can find the Microsoft All Rules rule set file at: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\Rule Sets\AllRules.ruleset.
Step Two – Minor Tweak
Next, I opened the pull.ruleset file in a text editor (it is just XML) and changed the rule set name and description.

Step Three – Associate
Next, I used the Browse option in the rule set selector to select my pull.ruleset file.
Step Four – Adjust Rules
Now, I could use the Visual Studio rules editor (by clicking Open) to adjust what rules I wanted to keep and what severity level to assign them. Since I started with the Microsoft All Rules, I had all the rules listed initially, so this took a little bit of time to adjust.

Step Five – Source Control
Make sure you check in your custom rule set file so that everyone on the team can enjoy its powerful magic. If I were using a fully featured ALM tool (like TFS) and not just a source control tool, I could also include the rules in my check-in policies to ensure that code checked in complies—and in my build server.