FAQ: Why does FxCop generate violations against itself? [Michael Fanning]

  • Article

We recently received a question regarding why FxCop violations occur against itself. This topic has already been partly covered by https://weblogs.asp.net/fxcop/archive/2004/01/08/48853.aspx but since there are a few FxCop-specific details for this variant of the question, I thought I'd post some additional comments.

-----Original Message-----
From: <MS Consultant>
Sent: Tuesday, February 10, 2004 12:39 PM
To: FxCop Team
Subject: FxCop turned on itself produces critical errors

A customer has been kind enough to point out that FxCop doesn’t seem to be following its own guidance. When I analyzed FxCop.exe I get 158 messages with 32 of them being critical errors. If anyone cares to comment I’d be happy to relay to the customer. J

----- Reply -----
From: Michael Fanning

Some comments:

1) FxCop messages are not always resolvable; there are often good reasons for not fixing a reported violation. Sometimes, unfortunately, we generate a false positive that's not easily eradicated. This is why we built an exclusions mechanism into the tool. (btw - your customer can use the ‘Certainty’ figure as a rough guide to how confident the violation is a problem that can and should be fixed).
2) FxCop.exe is not a reusable library so it is not subject to all the guidelines enforced by the tool. FxCop isn’t currently localized, so not all globalization\localization rules apply (this will change shortly). Etc.
3) Because we’re constantly writing new rules, we sometimes generate a check that reveals existing issues in our own app (which now exceeds 50k lines of non-commented code). We sometimes delay fixing these due to cost to resolve and/or an unacceptable level of churn in the code base while driving to a release date.
4) Finally, it’s difficult to measure an assembly’s code quality using number of messages as a metric. We generated 158 messages in FxCop.exe but also passed 30,000 other checks. You’d really need to look at the specific messages to gauge our level of irresponsibility. I can tell you that we run FxCop in advance of every check-in to insure that no new violations sneak in unnoticed. In our last internal release, we reviewed every existing violation and made an explicit decision not to fix each one we shipped.

The FxCop blog also has a related posting on this that explicitly addresses why .NET Framework assemblies report FxCop violations.

https://weblogs.asp.net/fxcop/archive/2004/01/08/48853.aspx

Michael