Code Analysis of Microsoft Assemblies [Michael Fanning]

For the (real) inaugural post, Michael Fanning explains why some shipped Microsoft managed assemblies have fxcop violations, a very good question. It's also a good insight into how we use FxCop internally at MS.

-----Original Message-----

From: <An FxCop User>

Sent: Thursday, January 08, 2004 2:49 AM
Subject: Code Analysis of Microsoft assemblies

Guys

Whilst were very keen on using your tool to ensure our assemblies conform to the microsoft design guidelines could you explain perhaps why analysis of a microsoft assembly such as System.dll results in 1161 violations of which over half are errors.

Do microsoft not use this tool or consult their own guidelines internally?

Many thanks
An FxCop User

----Original Message-----

From: Michael Fanning
Sent: Thursday, January 08, 2004 8:44 AM
To: 'An FxCop User'; FxCop External Customer Support
Subject: RE: Code Analysis of Microsoft assemblies

There are four primary reasons for the problem you've noticed:

1) The MS Design Guidelines were developed concurrently with the framework. Inconsistencies in the framework that were noticed often gave rise to a new FxCop check. In many cases, though, the appropriate time to fix a specific category of issue had already passed. The risk associated with an issue was low, the churn to the code was not, or the fix constituted a breaking change that would compromise early adopter usage and testing.

2) Some design considerations for reusable libraries are not, strictly speaking, relevant to the core system files of the framework.

3) The current release of FxCop contains many rules which have a relatively high noise factor. The checks are good and worth reviewing, but in many cases, there is not an actual issue.

4) FxCop development and usage itself always lagged behind the framework. By the time we shipped version 1.0, all framework development teams were aware of and used FxCop. Today, however, these teams run FxCop in advance of every check-in.

But that final point does not address the problem of an issue in code that has already shipped. FxCop fixes that constitute a breaking change for users are not approved except for very good reason (such as a security problem). This underscores the importance of tracking and fixing problems as they occur during a development cycle.

I hope the above is sensible. FxCop is used throughout the MS for managed code development and has twice been recognized as a 'best practice' tool by the company. The internal FxCop and Design Guideline discussion aliases contain 900+ developers and there is plenty of traffic. All groups define code analysis criteria for reviewing and fixing FxCop violations at each project milestone. As mentioned, it is a requirement for core framework development teams to run in advance of each check-in.

So we are busy walking the walk besides chatting up external customers on the subject. 8)

Thanks for using FxCop,

Michael