CA2000 passing object reference to base constructor in C#

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开发者_C百科 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.

---

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.

---

There is no safe and elegant way to have a chained constructor pass a new IDisposable object to the base constructor, since as you note it's not possible to wrap the chained constructor call in any sort of try finally block. There is an approach which is safe, but it's hardly elegant: define a utility method something like:

internal static TV storeAndReturn<TR,TV>(ref TR dest, TV value) where TV:TR
{ 
  dest = value; return value;
}

Have the constructor look something like:

protected DataGridViewMyCustomColumn(ref IDisposable cleaner) : 
   base(storeAndReturn(ref cleaner, new DataGridViewMyCustomCell()))
{
}

Code which needs a new object would then have to call a public static factory method which would call the appropriate constructor within a try/finally block whose main line would null out cleaner just before it finished, and whose finally block would call Dispose on cleaner if it's not null. Provided that every subclass defines a similar factory method, this approach will ensure that the new IDisposable object will get disposed even if an exception occurs between time it's created and the time the encapsulating object is exposed to client code. The pattern is ugly, but I'm not sure any nicer other pattern would assure correctness.