1

Я собираюсь создать для него новый поток, поскольку предыдущие принятые ответы больше не работают с VS2012 и выше. При использовании вложенных используя операторы, анализ Visual Studio код дает раздражающий CA2202 Не отчуждать объекты несколько раз, для следующего кода:Предупреждение о страхе CA2202 в анализе кода Visual Studio

using (MemoryStream msData = new MemoryStream(encodedData)) 
      { 
       using (BinaryWriter wtr = new BinaryWriter(msData)) 
       { 
        wtr.Write(IV, 0, IV.Length); 
        wtr.Write(encrypted, 0, encrypted.Length); 
       } 
      } 

Это раздражает, потому что даже в списке MSDN samples. У Microsoft даже есть recommended fix для этого предупреждения, однако оно больше не исправляет предупреждение. Это может работать или не работать для вас, в зависимости от того, какую версию/компилятор Visual Studio вы используете.

ответ

0

Приведенные выше код может быть фиксированным, должным образом, со следующим изменением к коду:

MemoryStream msData = null; 
try 
{ 
    msData = new MemoryStream(encodedData); 
    try 
    { 
     using (BinaryWriter wtr = new BinaryWriter(msData)) 
     { 
      wtr.Write(IV, 0, IV.Length); 
      wtr.Write(encrypted, 0, encrypted.Length); 
     } 
    } 
    finally 
    { 
     msData = null; 
    } 
} 
finally 
{ 
    if (msData != null) 
     msData.Dispose(); 
} 

Помимо кода быть гораздо менее читаемым, это решение. Похоже, что недавно они изменили анализ кода, и поскольку previously mentioned не требовал второго внутреннего блока try/finally. Однако я не понимаю, почему. Предыдущих исправлений должно быть достаточно, чтобы иметь дело с удалением объекта MemoryStream в случае исключения.

Я все еще думаю, что исключение CA2202 является фиктивным, и правильное решение - игнорировать предупреждение - базовые объекты не должны избавляться от ссылок, которыми он не владеет. Это просто для обсуждения и ссылки.

+0

Я никогда не понимал смысла этого предупреждения, особенно в этом сценарии. В договоре IDisposable явно указано, что вызов Dispose несколько раз должен быть безопасным. Единственная причина в том, чтобы предотвратить путаницу в отношении владения ресурсами. Тем не менее, «исправление» кода, как рекомендовано, является утомительным и подверженным ошибкам. Определенно не «яма успеха», на которую претендует Microsoft. –