CA2000 передает ссылку на объект базовому конструктору в C#

Если вы используете Visual Studio 2010, CA2000 полностью не работает. Он также может быть нарушен в других версиях FxCop (он же Code Analysis), но VS2010 — единственная, за которую я могу поручиться. Наша кодовая база выдает предупреждения CA2000 для кода, подобного этому...

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

...указывая, что соединение не удаляется до того, как оно выйдет из области действия метода. Что ж, да, это правда, но это не выходит за рамки для приложения, поскольку оно возвращается вызывающей стороне — в этом весь смысл метода! Точно так же ваш аргумент конструктора не выходит за пределы области видимости, а передается базовому классу, поэтому это скорее ложное срабатывание правила, чем реальная проблема.

Раньше это было полезным правилом, но теперь все, что вы действительно можете сделать, это отключить его, пока оно не будет исправлено. Что прискорбно, потому что (очень немногие) фактические положительные моменты должны быть исправлены.

Не существует безопасного и элегантного способа передать связанному конструктору новый объект IDisposable базовому конструктору, поскольку, как вы заметили, невозможно обернуть вызов связанного конструктора каким-либо блоком try finally. Есть безопасный, но вряд ли элегантный подход: определите служебный метод примерно так:

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

Пусть конструктор выглядит примерно так:

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

Код, который нуждается в новом объекте, затем должен был бы вызвать общедоступный статический фабричный метод, который вызвал бы соответствующий конструктор в блоке try/finally, основная строка которого обнуляла бы cleaner непосредственно перед ее завершением, а блок finally вызывал бы Dispose на cleaner, если это не ноль. При условии, что каждый подкласс определяет аналогичный фабричный метод, этот подход гарантирует, что новый объект IDisposable будет удален, даже если возникнет исключение между временем его создания и моментом, когда инкапсулирующий объект подвергается воздействию клиентского кода. Шаблон уродлив, но я не уверен, что какой-либо более красивый шаблон обеспечит правильность.