New FxCop rules from the community

Four or so years ago when we got serious about FxCop internally one of the main design points we had is that the community would not only find value in the rules we created, but would also add their own.  I see today that at least one person has started doing just that.  Thanks Brady


fxcop rule : checking for IDataReader in method parameters


Know of any others?


Comments (22)

  1. Pattern Guru says:

    Cool. At our company we are doing stuff with FxCop rules, but it’s specific for a sort of framework and application architecture we’re working on and so far it’s all still internal work. All of this means nothing about it can be found online. (Yet?)

  2. Anand says:

    Well I wrote some for the older versions. Have not had the time to update them, but I still get questions on writing new FxCop rules, because people read the information at my site,

    I wanted it to be more of a place where people can learn to write FxCop rules rather than be rules repository. Thats why I still have those source files there, even though most of those rules are now part of the FxCop release.

  3. says:

    I know that John Robbins wrote an article creating FxCop rule. You can find on

    And in the sample there are design rules and some Performance rules

  4. Jason Coyne says:

    What is the major problem with passing the DataReader to a constructor, vs any other kind of method? Does the constructor have some additional overhead in it?

    I can understand wanting to keep the datareader open for the minimum amount of time possible, but say you have a class (or class hierarchy) that represents a given database structure, woudlnt it make sense to pass the datareader into the contstructor or factory, and have everything built that way, and avoid the overhead of a datatable?

  5. brady gaster says:

    thanks for the link! i’m trying, but it ain’t easy to write these puppies!

  6. brady gaster says:

    Want to help me with a problem i’m having writing another rule? Take a look at this discussion on the GotDotNet FxCop board.


  7. Kris says:

    I’m with Jason on this one. I don’t see why using an IDataReader as a method argument is such a horrible thing. Obviously passing IDataReader across tiers/application boundaries is a bad thing. However, if you read the MS PAG on Performance you can see that they always advocate using IDataReader vs. the heavier DataSet, with the tenet that you use it within the same application layer. Having a factory method which accepts IDataReader or IDataRecord vs. DataSet/DataTable seems completely valid with this in mind.

  8. William Robertson says:

    Hoping to see a reply for why the IDataReader as a method parameter is bad. I just started doing that to use OleDbDataReader, SqlDataReader, and OracleDataReader in one wrapper.

  9. Ben says:

    I wouldn’t consider passing an IDataReader around to be bad, as long as it’s not passing through teirs anyway.

  10. I have started writing a few rules, including some that are used by Microsoft internally.

    <a href=""></a&gt;

Skip to main content