FxCop: SuppressMessage with Expiry

I was talking with Scott Baldwin just a few moments ago about some of work items that are currently in our TFS repository in the current iteration and whether they should be pushed into the next one. He said that a few of the work items are actually follow ups to FxCop warnings that he suppressed that he wants to come back and remove later.

A good example of the need to do this is CA1020 (Avoid namespaces with few types). Let us suppose you are a bit of an FxCop nazi and you have set all the FxCop warnings to errors. This little charmer (CA1020) will stop you dead in the early phases of your project while you are still buidling out your class libraries – so you effectively have to suppress it. Of course, you then create a work item to revisit it in a future iteration, but it can sometimes be difficult finding that code again.

Maybe there is a better solution? Some WikiWikiWeb implementations support this concept of “fading tags” where you can mark something as new, but in the future it will just revert to a standard rendering. A good example of this is the FoxProWki (thanks to Andrew Coates for pointing this feature out to me years ago).

Anyway – I thought maybe we could apply this feature to the [SuppressMessage] attribute in FxCop. What if we tagged suppressions like this:

[SupressMessage(…, Expires = “31/10/2006”)]

This way, when FxCop goes through and runs, if it strikes a suppression which has expired it ignores it. This way our code would scream at us when its time to look at it again.

Some people might not like this feature so you would need an option to “ignore expiries” on a per project basis for when people inherit someone elses code. They would also be able to do what Scott is doing today and create work items – but not everyone has a defect tracking system supporting them like we do.

What do you think?


4 thoughts on “FxCop: SuppressMessage with Expiry

  1. David M. Kean


    I don’t agree. There are a couple of problems I can see with this approach:

    1) How will this interact with Code Analysis policy? Do you really want to have to fix violations in code you don’t own to pass policy when all you are doing is making a simple bug fix?
    2) We (DevDiv) has found that postponing work does not work, you never get time to fix it later; Either you fix a violation now, or you suppress it and move on.

    I think a better approach instead, would be to raise violations at better times. For example, you could imagine raising naming violations as you type, correctness (bugs) at compile time, performance rules at run time, AvoidNamespacesWithFewTypes and similar rules during an API review, etc

    What do you think?



  2. Mitch Denny Post author

    Hi David,

    If you could do that, it would be cool. I think that in order for that to happen we need to be able to attach long running workflows to events such as check-ins and build quality change notifications.

    I think its also fair to say that the workflow inside Microsoft vs. outside Microsoft is probably a little bit different.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s