New FxCop 1.312

The busy folks on the FxCop team have posted a new release, 1.312.  There's 43 new rules and some of those rules look outstanding.  A couple of my favorites are the “Avoid unnecessary string creation” (which looks to see if you are creating extranious strings on the heap) and “Do not raise reserved exception types” (which ensures you don't throw something like System.Exception directly).  The Read Me file discusses all the new stuff.

The team changed the custom rule SDK yet again, but the changes are for the better.  See the Read Me for all the changes.  Since many people are using the rules I developed for FxCop as part of my June 2004 and September 2004 Bugslayer columns, I updated all the rules I did to support FxCop 1.312, which you can download here.  Porting the rules to the new SDK interface wasn't too bad.  In the near future, I'll post an article here at the site which describes what's necessary to do the porting.  If you have your own rules to port, take a look at the Empty Rule example in my code to see what's different.

For rule writers, one major feature has been added to FxCop 1.312: when loading a rule that has a broken XML description, it finally tells you exactly which part of the XML is wrong!  In previous versions it was a complete trial and error process to find the error in your XML description.  Now FxCop tells you in the output window exactly what piece was wrong and why.  It's a huge timesaver.  Thanks to the team for adding that.

If you have any ideas for rules, we'd love to hear about them!  Shoot me an email (john at this web site) or post in the comments.  The rules are fun to develop and if there are some good suggestions, I'll write them.

On Nov 9 2004 10:43 AMBy jrobbins
With 7 Comments John Robbins

Comments (7)

  1. Ade

    I feel the Fxcop rules are fine however there appears to be one naming convention that seems to be contradictory in Fxcop and Microsoft documentations. They say underscores are not allowed for camel cased class variables and at the same time you cant have properties named the same but differing in case, example of this is as follows: private string name; public string Name{ get{ return this.name } set{ this.name=value } } if I were to underscore private string name (e.g _name) as above I will be breaking the rules also. Your thoughts on this will be appreciated

  2. David M. Kean

    The Microsoft guidelines do not mention anywhere about not allowing underscores in private member variables, they only talk about public members.

  3. vin

    I have some trouble with the rules Exception XML Document tag is missing. FxCop give me the error in this example. Anyone have a solution ? /// <exception cref="System.StackOverflowException"> /// Lancé lorsqu'il y a des symboles invalides dans le format. /// </exception> private string Test () { string test = ""; try { if(test.Length > 0) { test= "HAHAHA"; } } catch (System.StackOverflowException exc) { if (exc.Message.Equals ("TOTO")) { throw new System.StackOverflowException (exc.Message); } } return test; }

  4. Satyajit

    Hi! I have some questions: 1. How to check local variable type of a function? 2. How to check Namespace name? Please help me....

  6. Patrick Smacchia

    Developers interested in FxCop should have a glance at the tool NDepend:
    http://www.NDepend.com

    NDepend analyses source code and .NET assemblies. It allows controlling the complexity, the internal dependencies and the quality of .NET code.

    NDepend provides a language (CQL Code Query Language) dedicated to query and constraint a codebase.

    It also comes from with advanced code visualization (Dependencies Matrix, Metric treemap, Box and Arrows graph...), more than 60 metrics, facilities to generate reports and to be integrated with mainstream build technologies and development tools.

    NDepend also allows to compare precisely different versions of your codebase.

  7. Dan Hibbert

    I was unable to download the new rules. Is it possible to make them available again?

Leave a Comment

Archives

Tags