Develop Reference

Memory stream closed?

How did the MemoryStream close when it has not reached the end of its using statement?
MusicDataStore musicData = MusicDataStore.TestData();
BinaryFormatter formatter = new BinaryFormatter();
using (MemoryStream memStream = new MemoryStream())
{
formatter.Serialize(memStream, musicData);
using (StreamReader reader = new StreamReader(memStream))
{
memStream.Position = 0;
Console.WriteLine(reader.ReadToEnd());
}
//deserialize
memStream.Position = 0;
MusicDataStore input = (MusicDataStore)formatter.Deserialize(memStream);
}
I should be able to deserialize the memStream but it cannot be read because it is closed.
When I tried removing the StreamReader block I can successfully deserialize the memStream. Why? What's happening to memStream in StreamReader block?

StreamReader takes ownership of the Stream it's given, and will close it when it is disposed (most of the types which take another IDisposable type in their constructor will do this).
This StreamReader constructor takes a boolean saying whether to leave the stream open after the StreamReader is disposed as its last parameter:
using (var reader = new StreamReader(memStream, Encoding.UTF8, true, 1024, true))
{
...
}
(Those other parameters are the defaults which StreamReader(Stream) uses, from the referencesource.)
As Marc Gravell rightly notes in the comments, we've said to use UTF-8 encoding, but it looks like your stream is binary and definitely not UTF-8 text! So expect this to fail in practice. It may be more useful to look at the output of BitConverter.ToString(memStream.GetBuffer(), 0, memStream.Length) (or more simply but less efficiently BitConverter.ToString(memStream.ToArray())).

Is PdfStamper disposing output stream? (iTextSharp)

I am using iTextSharp to add page numbers to a PDF with C#. While running code analysis the MemoryStream for the output is suspected to be disposed more than once. See this warning generated by Visual Studio. Is this an API problem? Should the second parameter of PdfStamper be marked as out? Is there a way for me to fix this warning?
MemoryStream mem = null;
PdfReader reader = null;
PdfStamper stamper = null;
try
{
mem = new MemoryStream();
reader = new PdfReader(m_pdf);
stamper = new PdfStamper(reader, mem);
// do stuff
stamper.Close();
var result = mem.ToArray();
}
finally
{
if(stamper != null)
{
stamper.Dispose();
}
if (reader != null)
{
reader.Dispose();
}
if (mem != null)
{
mem.Dispose();
}
}

This isn't really an answer but to expand upon what #mkl said, switch over to using directives since those perform the try/finally stuff for you automatically.
Below is the way I (and probably everyone else that uses iTextSharp) would generally recommend to interact with iTextSharp. The outer using is BCL stuff, in this case the MemoryStream and the inner using statements are iTextSharp stuff.
//Will hold our raw PDF bytes
Byte[] result;
//BCL stuff first
using (var mem = new MemoryStream()) {
//iText stuff in the middle
using (var reader = new PdfReader(m_pdf)) {
using (var stamper = new PdfStamper(reader, mem)) {
// do stuff
}
}
//iText is completely done and disposed of at this point
//so we can now grab the raw bytes that represent a PDF
result = mem.ToArray();
}
As an aside, not necessarily for the OP but just in case someone else sees this, there is almost never (and by "almost never" I really mean "never") a good reason to not close the underlying stream. You can read from the stream by grabbing the raw bytes and writing to it again never makes sense.

The following allowed me to keep the MemoryStream open after the stamper is closed:
pdfStamper.Writer.CloseStream = false;

Disposing of object multiple times

I have the following code, which uses a stream to open and modify an Open XML document, and then save the new binary representation of that stream:
MemoryStream stream = null;
try
{
stream = new MemoryStream();
stream.Write(this.GetBinaryRepresentation(), 0, this.GetBinaryRepresentation().Length);
using (WordprocessingDocument document = WordprocessingDocument.Open(stream, true))
{
OfficeDocument.ModifyDocument(document);
this.SetBinaryRepresentation(stream.ToArray());
stream = null;
}
}
finally
{
if (stream != null)
{
stream.Dispose();
}
}
I had originally used two using blocks (one for the MemoryStream and the second for the WordprocessingDocument), but received warning CA2202: "Object 'stream' can be disposed more than once in method..." Per the MSDN article, I modified the code to above (converting the outer using to a try), but I am still receiving this warning.
I'm unsure of how I can structure this method to ensure that Dispose is called exactly once on the stream. I would prefer not to simply suppress this warning since the MSDN article states that you shouldn't rely on Dispose being safely callable multiple times.

Disposing of an object multiple times should always be safe. From the documentation for Dispose:
If an object's Dispose method is called more than once, the object must ignore all calls after the first one. The object must not throw an exception if its Dispose method is called multiple times.
That being said, a using statement is definitely the way to go here. The only reason you'd receive that method was if you were explicitly disposing of the object, which would not be required, as the using statement should always dispose the object exactly once.

The reason that the example from the MSDN article did not work for you is that they set the stream to null as soon as they enter the using block, whereas you use the stream inside your using block and set the stream to null after. If an exception is thrown before your stream = null statement, stream would be disposed of as the using block is exited, and then again in your finally block.
Unfortunately, since you need to access your stream after document has updated it, I don't see a clean way to use their example of setting stream = null within your using statement to avoid the multiple Dispose() calls. An alternative would be to you could declare both stream and document outside of the try block, and then clean both of them up inside your finally, like so:
MemoryStream stream = null;
WordprocessingDocument document = null;
try
{
stream = new MemoryStream();
stream.Write(this.GetBinaryRepresentation(), 0, this.GetBinaryRepresentation().Length);
document = WordprocessingDocument.Open(stream, true));
OfficeDocument.ModifyDocument(document);
this.SetBinaryRepresentation(stream.ToArray());
}
finally
{
if( document != null)
{
document.Dispose();
}
// Catch the case where an error occurred before document was defined.
else
{
stream.Dispose();
}
}

The stream may still be disposed twice if an exception is thrown in the using block before stream is set to null. Try this:
MemoryStream stream = null;
MemoryStream streamToDispose = null;
try
{
streamToDispose = stream = new MemoryStream();
stream.Write(this.GetBinaryRepresentation(), 0, this.GetBinaryRepresentation().Length);
using (WordprocessingDocument document = WordprocessingDocument.Open(stream, true))
{
streamToDispose = null;
OfficeDocument.ModifyDocument(document);
this.SetBinaryRepresentation(stream.ToArray());
}
}
finally
{
if (streamToDispose != null)
{
streamToDispose.Dispose();
}
}

The using statement disposes the object - so essentially you are calling dispose twice

When your code leaves the using block around the WordProcessingDocument, it will call dispose.
using (WordprocessingDocument document = WordprocessingDocument.Open(stream, true))
Since the WordProcessingDocument takes an instance of stream in its constructor, it will call dispose on that stream instance when WordProcessingDocument.Dispose is called. You then enter the finally block where you call stream.Dispose() - you have now called Dispose() on the stream instance twice.

Code Anlysis Rule CA2000 / CA2202

I am trying to ensure my coding follows correct disposal of objects so I am enforcing these rules as errors. But I am having trouble with this section of code
using System;
using System.IO;
using System.Runtime.Serialization;
using System.Xml;
class MyClass
{
public String ToXml()
{
var objSerializer =
new DataContractSerializer(GetType());
var objStream = new MemoryStream();
StreamReader objReader;
String strResult;
try
{
// Serialize the object
objSerializer.WriteObject(objStream, this);
// Move to start of stream to read out contents
objStream.Seek(0, SeekOrigin.Begin);
objReader = new StreamReader(objStream);
try
{
// Read Contents into a string
strResult = objReader.ReadToEnd();
}
finally
{
objReader.Dispose();
}
}
finally
{
if (objStream != null)
{
// objStream.Dispose();
}
}
return strResult;
}
}
If I comment out objStream.Dispose() I get CA2000 as I am not disposing the object but if I remove the comment it then says I am disposing more than once.
What else is disposing the object? or am I just doing this wrong when dealing with multiple streams?

This scenario has been annoying me as well now. Every couple of years I decide to refresh myself of the code analysis "rules" by running fxcop or the now built-in code analysis in Visual Studio.
I originally wrote this code, thinking I was being a good citizen for properly using usings to dispose:
using (MemoryStream msDecrypt = new MemoryStream())
{
using (CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Write))
{
csDecrypt.Write(eop.m_Ciphertext, 0, eop.m_Ciphertext.Length);
}
decrypted = msDecrypt.ToArray();
}
This block of code results in a CA2202 "Do not dispose objects multiple times" The great irony about this rule, is that it's not really about a problem with your code, as much as it is protecting you about a problem in others code. Microsoft has always had a decent amount of documentation about how the Dispose pattern (http://msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.110).aspx) should be implmented. However, by looking at the details of this code analysis rule (http://msdn.microsoft.com/en-us/library/ms182334.aspx) it reveals the purpose of this rule
"A correctly implemented Dispose method can be called multiple times
without throwing an exception. However, this is not guaranteed and to
avoid generating a System.ObjectDisposedException you should not call
Dispose more than one time on an object."
In short, this rule is all about protecting yourself from people who don't follow the rules.
Naturally I modified the code to look like this:
MemoryStream msDecrypt = new MemoryStream()
//using (MemoryStream msDecrypt = new MemoryStream())
//{
using (CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Write))
{
csDecrypt.Write(eop.m_Ciphertext, 0, eop.m_Ciphertext.Length);
}
decrypted = msDecrypt.ToArray();
//}
Now everybody on this stack overflow post is painfully aware of the new problem, our friend CA2000 "Dispose objects before losing scope" ... so at this point I just face palmed for a minute. Did a few Google searches, and found this post. That's when it dawned on me, to pass for both CA rules, you need to ensure everything is disposed once and only once for all code branches. So I set out to do this, which isn't a hard problem once you realize this is what you need to do.
Naturally, the code evolved to this:
MemoryStream msDecrypt = null;
CryptoStream csDecrypt = null;
try
{
msDecrypt = new MemoryStream();
csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Write);
csDecrypt.Write(eop.m_Ciphertext, 0, eop.m_Ciphertext.Length);
csDecrypt.FlushFinalBlock();
decrypted = msDecrypt.ToArray();
}
finally
{
if (csDecrypt != null)
{
csDecrypt.Dispose();
}
else if (msDecrypt != null)
{
msDecrypt.Dispose();
}
}
Finally, I had code that didn't result in a CA2000 or CA2202. The moral of the story is that the USING statement, is a lot less valuable than it was in the past now that code analysis rules have evolved in this way.
There are a few different ways you can write the code to make this work, I just chose a way that doesn't mix explicit calls to dispose with using statements, because I believe this to be simpler to read as well as structured in a way that would prevent someone from just going and wrapping another using around it, resulting in the originally issue unknowingly.

If you dispose the StreamReader, you are also disposing the underlying stream.
If you comment out objStream.Dispose() then you run into the chance of something throwing an exception before you even get to the nested try block - which will result in your stream not getting disposed.
There's a nice explanation here:
Does disposing streamreader close the stream?

This is not the answer, but you might find this code more readable:
public String ToXml()
{
var objSerializer =
new DataContractSerializer(GetType());
using (var objStream = new MemoryStream())
{
// Serialize the object
objSerializer.WriteObject(objStream, this);
// Move to start of stream to read
// out contents
objStream.Seek(0, SeekOrigin.Begin);
using (var objReader =
new StreamReader(objStream))
{
// Read Contents into a string
retirm objReader.ReadToEnd();
}
}
}

"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.