How do you start with FxCop on legacy code?

Question

Does anyone have any experience of introducing FxCop to legacy code? We would like to have our build fail if anyone introduces code that violates rules. But for the time being, this is impossible, as the legacy code has over 9000 violations.

The only way to suppress errors I know of is through the SuppressMessage attribute, but that only works on methods, and the GeneratedCodeAttribute. This last one could be used for classes and namespaces (if I recall correctly), but shouldn't be used for non-generated code (see here).

Right now, we take some time each day to remove violations, but new ones keep being introduced, because our build won't fail.

Any ideas?

Answer 1

Start by asking yourself this: Are you willing and able to change the legacy code to conform with FxCop rules? Or to put it differently: Is this the best way to spend your time?

If you are willing to spend the time and effort, start by picking the small handful of rules you find most important for the overall quality and implement those. If this is helpful you can add a few rules, fix code and so forth.

In my experience there's no big bang approach for implementing FxCop rules and the like. The only feasible way is to take small chunks at a time.

Answer 2

You can add exceptions for old violations in a FxCop project. That way you won't need to add any attributes to your existing code, and you will get warnings about all new violations.

To do that create a project in the FxCop GUI, run analysis with your rules, then in results view select violation you want to ignore for now. Right-click and choose "Exclude". Selected warnings will move to "excluded in project" tab. When you are ready to get back and fix them, select and click "mark as active".

These exclusions are stored in the .FxCop file.

Still, I'd recommend to introduce rules gradually, to smooth learning curve for everyone.

Answer 3

I have been in a similar situation. I started using FxCop on an existing project some time ago, and had quite a few errors at the start. What I did was to turn off all the rules, then turn on one group at a time, resolving errors as I went.

The Security and Performance groups are a good place to start - they helped me find issues I was not aware of before. Some of the rules are subjective, and may not fully apply to your project, if at all. For example, if internationalization is not an issue, then leave that group turned off. If there are specific rules that do not apply to you, such as naming rules, then turn them off.

If you manage to clear out a set of errors for a certain rule, you can set the build to fail if that rules is violated in the future. So no new errors will creep in.

If it's a project of some size, just go a rule at a time, review the rule's relevance/importance, and either fix the errors or turn the rule off if it does not apply.

Answer 4

How about the following approach:

1. Run FXCop with all rules on that are relevant for your project
2. Save results as a baseline
3. Develop new code
4. Run FxCop
5. Remove all results from the baseline

this will result on fxcop checks on your new code....