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


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,



Comments (16)

  1. PP says:

    All very well but FXcop violations are not limited to the .NET framework assemblies. All the "best Practice" Applications blocks released by the patterns and practices folks at Microsoft have loads of Fxcop violations as well. As an example , the Data Access Application Block contains 50 violations !!

  2. GL says:

    Hi there,

    I am trying to get FXCop to analyze one of our bigger and more advanced projects. I am now running into trouble that more than half the files can either not be opened be FXCop or FXCop can open them but crashes. In the project we have to interact with non managed code, is that one of the reasons why this happens? In addition I ran PEVerify and there I also get some IL errors?! I am not sure why, becuase I can open the assembly fine with the ILDASM tool.

    Since I was reading that MS is using FXCop over all products I was wondering if you hear a lot about prblems like that or if this is an isolated case. Also as I understand in the next version FXCop will use a new IL parser, will that address that problem?

  3. Jeffrey van Gogh says:

    Hi GL,

    Sorry to hear you’re having such problems using FxCop. Can you contact us via email: asfxcop AT so we can help you resolve this issue? Things we would like to know:

    -What errors are you seeing?

    -What language did you use to build this assembly?

    -What errors did PEVerify show?

    -What version of the framework did you use to compile your assembly with, is FxCop running on that same version (See Help about to check which version FxCop is running on).


    Jeffrey van Gogh

    FxCop Team

  4. Jeffrey van Gogh says:

    That address should ofcourse be: asKfxcop At

  5. Eric Newton says:

    people relax… fxcop is a design GUIDELINES check, not neccesarily a code-correctness check.

    If System.dll had 1600 true errors, do you think we’d be happy go-lucky .Net developers? or raging lunatics bent on hair pulling…

    again, relax

  6. Jeffrey van Gogh says:

    Hi Eric,

    FxCop does check both Design Guidelines, as well as Code-correctness issues, the ratio is about 50%-50%. You’re right though that most of the issues in System.dll are Design Guidelines violations.


    Jeffrey van Gogh

    FxCop Team

  7. Vinod says:

    I have a specific design rule to check in my Presentation Layer. I have to check whether any one of the development team has mistakenly created an Instance of DataAccessHelper in the Web Layer. I should be able to check even within a method whether an Instance of the DAL is created. How is it possible to write a Custom rule for such situations using FxCop?



  8. Jeffrey van Gogh says:

    Hi Vinod,

    first I’d recommend to take a look at this article from MSDN Magazine: It talks about how to write custom fxcop rules.

    Then about your specific question. I’d walk the Method.Instructions and see if you find a instruction with OpCode.Newobj that has a value that is a InstanceInitailizer of the DataAccessHelper type.



  9. Vinod says:

    Hi Jeffrey,

    Is it possible for you to post a sample code on the same.



  10. Jeffrey van Gogh says:

    sure, provided you get the basic rules running from the article, here’s some sample code:

    public Problem[] Check(Method method)


    for(int i=0; i < method.Instructions.Length; i++)


    Instruction instruction = method.Instructions[i];



    case OpCode.Newobj:

    InstanceInitializer cons = instruction.Value as InstanceInitializer;

    if (cons.DeclaringType == MyTypeThatIsNotAllowed)


    Problems.Add(GetResolution(cons.FullName), instruction);




    return Problems.AsArray();


  11. Vinod says:

    Thanks a lot Jeffry. Interospection solved the issue. When will be the release for the Interospection help documentation.?



Skip to main content