Develop Reference

Cannot get rid of CA2202 warning

I have read the MSDN page on this: https://msdn.microsoft.com/en-us/library/ms182334.aspx
And also this SO answer: https://stackoverflow.com/a/32554589/2257227
But the following code still generates 2 CA2202 warnings for me:
FileStream fileStream = null;
BufferedStream bufferedStream = null;
try
{
fileStream = File.Open(...);
bufferedStream = new BufferedStream(fileStream);
using (StreamReader streamReader = new StreamReader(bufferedStream))
{
...
}
}
finally
{
if (bufferedStream != null)
{
bufferedStream.Dispose();
}
if (fileStream != null)
{
fileStream.Dispose();
}
}
The "bufferedStream.Dispose()" line still gives the following two warnings:
Severity Code Description Project File Line Suppression State
Warning CA2202 Object 'bufferedStream' can be disposed more than once in method 'Loader.UpdateIndex()'. To avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object.: Lines: 930 Loader C:\Users\user\Loader\Loader.cs 930 Active
and
Severity Code Description Project File Line Suppression State
Warning CA2202 Object 'fileStream' can be disposed more than once in method 'Loader.UpdateIndex()'. To avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object.: Lines: 930, 935 Loader C:\Users\user\Loader\Loader.cs 930 Active
Presumably this is because fileStream could be disposed of more than once? But how can bufferedStream be disposed of more than once?
Edit: I've marked #Damien_The_Unbeliever's answer as correct. You can actually trim it down as well, because as was mentioned somewhere below, you don't need the bufferedReader variable. Here's what I ended up with. It's kinda ugly, but it works:
FileStream fileStream = null;
try
{
fileStream = File.Open("iaushdiuh", FileMode.Open);
fileStream = null;
using (StreamReader streamReader = new StreamReader(fileStream))
{
streamReader.ReadLine();
}
}
finally
{
if (fileStream != null)
{
fileStream.Dispose();
}
}

If you don't use the underlying streams after you've "passed ownership" of these objects to other objects, you can silence the warning like this:
FileStream fileStream = null;
BufferedStream bufferedStream = null;
try
{
fileStream = File.Open(...);
bufferedStream = new BufferedStream(fileStream);
fileStream = null;
using (StreamReader streamReader = new StreamReader(bufferedStream))
{
bufferedStream = null;
...
}
}
finally
{
if (bufferedStream != null)
{
bufferedStream.Dispose();
}
if (fileStream != null)
{
fileStream.Dispose();
}
}
You'll want the assignments to null to occur immediately following the constructor call that "takes ownership" of the disposable object. In this way, you ensure that if the constructor throws, you dispose the inner object and if the constructor succeeds then it is then going to arrange for disposal to occur.

WPF code analyze : CA2202 Do not dispose objects multiple timesObject

in my WPF application code i got the following Warnings:
CA2202 Do not dispose objects multiple times Object 'fs' can be
disposed more than once in method
'MainWindow.TestResults_Click(object, RoutedEventArgs)'. To avoid
generating a System.ObjectDisposedException you should not call
Dispose more than one time on an object. : Lines:
429 yesMonitor MainWindow.xaml.cs 429
for code:
FileStream fs = new FileStream(System.AppDomain.CurrentDomain.BaseDirectory + "TestResult.htm", FileMode.Create);
using (fs)
{
using (StreamWriter w = new StreamWriter(fs, Encoding.UTF8))
{
w.WriteLine(GetTestResultsHtml());
}
}
what should be the reason for these warning?

Nested using statements can cause violations of the CA2202 warning. If the IDisposable resource of the nested inner using statement contains the resource of the outer using statement, the Dispose method of the nested resource releases the contained resource. When this situation occurs, the Dispose method of the outer using statement attempts to dispose its resource for a second time.
In the following example, a Stream object that is created in an outer using statement is released at the end of the inner using statement in the Dispose method of the StreamWriter object that contains the stream object. At the end of the outer using statement, the stream object is released a second time. The second release is a violation of CA2202.
using (Stream stream = new FileStream("file.txt", FileMode.OpenOrCreate))
{
using (StreamWriter writer = new StreamWriter(stream))
{
// Use the writer object...
}
}
To resolve this issue, use a try/finally block instead of the outer using statement. In the finally block, make sure that the stream resource is not null.
Stream stream = null;
try
{
stream = new FileStream("file.txt", FileMode.OpenOrCreate);
using (StreamWriter writer = new StreamWriter(stream))
{
stream = null;
// Use the writer object...
}
}
finally
{
if(stream != null)
stream.Dispose();
}

Personally in this case I would use:
public StreamWriter(
string path,
bool append
)
Initializes a new instance of the StreamWriter class for the specified
file by using the default encoding and buffer size. If the file
exists, it can be either overwritten or appended to. If the file does
not exist, this constructor creates a new file.
But there is NO good solution, see CA2202, how to solve this case

how to close network stream connection properly?

I have an application that is connecting to some network server (tcp) and is connected using a network stream:
if (!SSL)
{
_networkStream = new System.Net.Sockets.TcpClient(Server, Port).GetStream();
_StreamWriter = new System.IO.StreamWriter(_networkStream);
_StreamReader = new System.IO.StreamReader(_networkStream, Encoding.UTF8);
}
if (SSL)
{
System.Net.Sockets.TcpClient client = new System.Net.Sockets.TcpClient(Server, Port);
_networkSsl = new System.Net.Security.SslStream(client.GetStream(), false,
new System.Net.Security.RemoteCertificateValidationCallback(Protocol.ValidateServerCertificate), null);
_networkSsl.AuthenticateAsClient(Server);
_StreamWriter = new System.IO.StreamWriter(_networkSsl);
_StreamReader = new System.IO.StreamReader(_networkSsl, Encoding.UTF8);
}
///// since now I working with both reader and writer globally in multiple threads
I am using reader and writer asynchronously (in 2 threads) and I need to have both of these streams globally available (they are defined as public references on class level), so I don't know if using statement can be used here.
How should I properly close this connection? All objects (NetworkStream, stream writer and reader) have the Close() method. Should I call it for all of them? Or only 1 of them? Is there any need to release some resources?

Put them in a using block. It will close and dispose of each stream appropriately after the operation has been completed.
using (StreamReader reader = new StreamReader(_networkStream, Encoding.UTF8))
{
}

Use using() {} blocks. This way all Connections/streams are properly closed after usage.
using(_networkStream = new System.Net.Sockets.TcpClient(Server, Port).GetStream())
{
using(_StreamWriter = new System.IO.StreamWriter(_networkStream))
{
//do stuff
}
using(_StreamReader = new System.IO.StreamReader(_networkStream, Encoding.UTF8))
{
//do stuff
}
}

When they are disposed of, StreamReader and StreamWriter each dispose of the underlying NetworkStream automatically by default. Because of this, if you are using both a reader and a writer, you might get an "object already disposed" type of exception when you try to close the second one. I prefer to dispose of the stream itself but not the reader/writer since it's pointless in that case.
using stream = tcpClient.GetStream();
var reader = new StreamReader(stream);
var writer = new StreamWriter(stream);
// <use reader and writer>
// <the using statement ensures the stream is disposed of>
If you insist on disposing of the reader and writer, you can disable their default auto-close-the-stream behavior via the leaveOpen parameter:
new StreamReader(stream, leaveOpen: true)
new StreamWriter(stream, leaveOpen: true)
Making use of using is ideal if possible, but the other way to accomplish the same is to manually call the stream's Close() method or, equivalently, its Dispose() method.

"Object can be disposed of more than once" error

When I run code analysis on the following chunk of code I get this message:
Object 'stream' can be disposed more than once in method 'upload.Page_Load(object, EventArgs)'. To avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object.
using(var stream = File.Open(newFilename, FileMode.CreateNew))
using(var reader = new BinaryReader(file.InputStream))
using(var writer = new BinaryWriter(stream))
{
var chunk = new byte[ChunkSize];
Int32 count;
while((count = reader.Read(chunk, 0, ChunkSize)) > 0)
{
writer.Write(chunk, 0, count);
}
}
I don't understand why it might be called twice, and how to fix it to eliminate the error. Any help?

I struggled with this problem and found the example here to be very helpful. I'll post the code for a quick view:
using (Stream stream = new FileStream("file.txt", FileMode.OpenOrCreate))
{
using (StreamWriter writer = new StreamWriter(stream))
{
// Use the writer object...
}
}
Replace the outer using statement with a try/finally making sure to BOTH null the stream after using it in StreamWriter AND check to make sure it is not null in the finally before disposing.
Stream stream = null;
try
{
stream = new FileStream("file.txt", FileMode.OpenOrCreate);
using (StreamWriter writer = new StreamWriter(stream))
{
stream = null;
// Use the writer object...
}
}
finally
{
if(stream != null)
stream.Dispose();
}
Doing this cleared up my errors.

To illustrate, let's edit your code
using(var stream = File.Open(newFilename, FileMode.CreateNew))
{
using(var reader = new BinaryReader(file.InputStream))
{
using(var writer = new BinaryWriter(stream))
{
var chunk = new byte[ChunkSize];
Int32 count;
while((count = reader.Read(chunk, 0, ChunkSize)) > 0)
{
writer.Write(chunk, 0, count);
}
} // here we dispose of writer, which disposes of stream
} // here we dispose of reader
} // here we dispose a stream, which was already disposed of by writer
To avoid this, just create the writer directly
using(var reader = new BinaryReader(file.InputStream))
{
using(var writer = new BinaryWriter( File.Open(newFilename, FileMode.CreateNew)))
{
var chunk = new byte[ChunkSize];
Int32 count;
while((count = reader.Read(chunk, 0, ChunkSize)) > 0)
{
writer.Write(chunk, 0, count);
}
} // here we dispose of writer, which disposes of its inner stream
} // here we dispose of reader
edit: to take into account what Eric Lippert is saying, there could indeed be a moment when the stream is only released by the finalizer if BinaryWriter throws an exception. According to the BinaryWriter code, that could occur in three cases
If (output Is Nothing) Then
Throw New ArgumentNullException("output")
End If
If (encoding Is Nothing) Then
Throw New ArgumentNullException("encoding")
End If
If Not output.CanWrite Then
Throw New ArgumentException(Environment.GetResourceString("Argument_StreamNotWritable"))
End If
if you didn't specify an output, ie if stream is null. That shouldn't be a problem since a null stream means no resources to dispose of :)
if you didn't specify an encoding. since we don't use the constructor form where the encoding is specified, there should be no problem here either (i didn't look into the encoding contructor too much, but an invalid codepage can throw)
if you don't pass a writable stream. That should be caught quite quickly during development...
Anyway, good point, hence the edit :)

The BinaryReader/BinaryWriter will dispose the underlying stream for you when it disposes. You don't need to do it explicitly.
To fix it you can remove the using around the Stream itself.

A proper implementation of Dispose is explicitly required not to care if it's been called more than once on the same object. While multiple calls to Dispose are sometimes indicative of logic problems or code which could be better written, the only way I would improve the original posted code would be to convince Microsoft to add an option to BinaryReader and BinaryWriter instructing them not to dispose their passed-in stream (and then use that option). Otherwise, the code required to ensure the file gets closed even if the reader or writer throws in its constructor would be sufficiently ugly that simply letting the file get disposed more than once would seem cleaner.

Your writer will dispose your stream, always.

Suppress CA2202 whenever you are sure that the object in question handles multiple Dispose calls correctly and that your control flow is impeccably readable. BCL objects generally implement Dispose correctly. Streams are famous for that.
But don't necessarily trust third party or your own streams if you don't have unit tests probing that scenario yet. An API which returns a Stream may be returning a fragile subclass.

C# CA2000:Dispose objects before losing scope using FileStream/XmlTextReader

I have lots of code like this:
FileStream fs = File.Open(#"C:\Temp\SNB-RSS.xml", FileMode.Open);
using (XmlTextReader reader = new XmlTextReader(fs))
{
/* Some other code */
}
This gives me the following Code Analysis warning:
CA2000 : Microsoft.Reliability : In method 'SF_Tester.Run()', object 'fs' is not disposed along all exception paths. Call System.IDisposable.Dispose on object 'fs' before all references to it are out of scope.
If I follow the suggestion and I put the File.Open in a using statement, I get this:
CA2202 : Microsoft.Usage : Object 'fs' can be disposed more than once in method 'SF_Tester.Run()'. To avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object.: Lines: 39
I'm using VS2010 and I can't help but think I'm doing something wrong but I don't see it.
What am I doing wrong?

Sigh, exhausting isn't it. Avoid all this by using the recommended Create() method:
using (var reader = XmlReader.Create(#"C:\Temp\SNB-RSS.xml")) {
//...
}

As nobody provided a solution that solves this issue yet, I'm writing my working solution down here:
FileStream fs = new FileStream(fileName, FileMode.Truncate, FileAccess.ReadWrite, FileShare.ReadWrite);
try
{
using (var fileWriter = new StreamWriter(fs, encoding))
{
fs = null;
fileWriter.Write(content);
}
}
finally
{
if (fs != null)
fs.Dispose();
}
This removes CA2000.

I am only guessing; don't have time to go through a full analysis now.
Suppose the XmlTextReader constructor 'takes ownership' of the stream passed in, and so disposing the XmlTextReader will also Dispose the underlying stream. That would explain the behavior you see. Perhaps XmlTextReader constructor can throw, and in that instance, the original warning about fs would make sense. However, given that hypothesis, this code
var fs = File.Open(#"C:\Temp\SNB-RSS.xml", FileMode.Open);
XmlTextReader reader = null;
try
{
reader = new XmlTextReader(fs);
}
finally
{
if (reader== null)
{
fs.Dispose();
}
}
if (reader != null)
{
using (reader)
{
/* Some other code */
}
}
is, I think, correct, but still yields a spurious warning. This smells like a nice example that demonstrates the limitations of static analysis tools.
As someone else said, there is another API to directly create the reader from the filename (XmlReader.Create()), which avoids all this (and shows how well-designed scenario-focused APIs are a good thing for a surprising variety of reasons).

It's a known issue
http://connect.microsoft.com/VisualStudio/feedback/details/535118/ca2000-and-ca2202-offer-contradictory-warnings
If you're using a StreamWriter rather than XmlTextReader (as in the solution above) you could use a similar method via the relevant constructor; e.g.
var sw = new StreamWriter("filename.txt");
or
var sw = new StreamWriter("filename.txt", /*append to file = */ false );
It is not clear from the documentation whether the first form of constructor will overwrite or append to a file.

As mentioned in this answer, the only way to work around it correctly is to do as recommended in CA2202 and use an outer try-finally block instead of an outer using block. Inside the inner using, set the outer IDisposable object to null to prevent it from being accessed once the inner using has finished.
Here's a generic wrapper that does it "correctly", i.e. works around the badly designed XmlReader (maybe it should not have taken ownership of the stream it receives? Not sure what the right way to do it would be)
Disclaimer: Not really tested
public static TResult SafeNestedUsing<TOuter, TInner, TResult>(Func<TOuter> createOuterDisposable, Func<TOuter, TInner> createInnerDisposable, Func<TInner, TResult> body)
where TInner : IDisposable
where TOuter : class, IDisposable
{
TOuter outer = null;
try
{
outer = createOuterDisposable();
using (var inner = createInnerDisposable(outer))
{
var result = body(inner);
outer = null;
return result;
}
}
finally
{
if (null != outer)
{
outer.Dispose();
}
}
}
Example usage:
SafeNestedUsing<MemoryStream, XmlReader, XmlDocument>(
() => new MemoryStream(array),
(memStream) => XmlReader.Create(memStream, xmlReaderSettings),
(xmlReader) =>
{
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.Load(xmlReader);
return xmlDoc;
});
This is quite clunky, and you may argue that it's better to repeat the try/set null/finally pattern instead. But for a repeating pattern of nested usings I'd rather do it this way than repeat the full thing each time.

just use 'using' for the filestream
using(FileStream fs = new FileStream(fileName, FileMode.Truncate, FileAccess.ReadWrite, FileShare.ReadWrite))
{
// some codes here
}
Don't modify fs and don't use fs.close() inside using curly braces.

Use the using statement also on the FileStream itself just like on the XmlTextReader.
http://msdn.microsoft.com/en-us/library/system.io.filestream(VS.71).aspx.
Grz, Kris.