Question

I receive a warning when I run some code through Visual Studio’s Code Analysis utility which I’m not sure how to resolve. Perhaps someone here has come across a similar issue, resolved it, and is willing to share their insight.

I’m programming a custom-painted cell used in a DataGridView control. The code resembles:

public class DataGridViewMyCustomColumn : DataGridViewColumn
{
    public DataGridViewMyCustomColumn() : base(new DataGridViewMyCustomCell())
    {
    }

It generates the following warning:

CA2000 : Microsoft.Reliability : In method ‘DataGridViewMyCustomColumn.DataGridViewMyCustomColumn()’ call System.IDisposable.Dispose on object ‘new DataGridViewMyCustomCell()’ before all references to it are out of scope.

I understand it is warning me DataGridViewMyCustomCell (or a class that it inherits from) implements the IDisposable interface and the Dispose() method should be called to clean up any resources claimed by DataGridViewMyCustomCell when it is no longer.

The examples I’ve seen on the internet suggest a using block to scope the lifetime of the object and have the system automatically dispose it, but base isn’t recognized when moved into the body of the constructor so I can’t write a using block around it… which I’m not sure I’d want to do anyway, since wouldn’t that instruct the run time to free the object which could still be used later inside the base class?

My question then, is the code okay as is? Or, how could it be refactored to resolve the warning? I don’t want to suppress the warning unless it is truly appropriate to do so.

Answer 1

If you’re using Visual Studio 2010 then CA2000 is completely broken. It may also be broken in other versions of FxCop (a.k.a. Code Analysis), but VS2010 is the only one I can vouch for. Our codebase is giving CA2000 warnings for code like this…

internal static class ConnectionManager 
{
    public static SqlConnection CreateConnection()
    {
         return new SqlConnection("our connection string");
    }
}

…indicating that the connection is not being disposed before it goes out of scope in the method. Well, yeah, that’s true, but it isn’t out of scope for the application as it’s returned to a caller – that’s the whole point of the method! In the same way, your constructor argument isn’t going out of scope but is being passed to the base class, so it’s a false positive from the rule rather than an actual problem.

This used to be a useful rule, but now all you can really do is turn it off until they fix it. Which is unfortunate, because the (very few) actual positives are things that should be fixed.