I have an interesting scenario with writing and reading data from streams in .NET 4. This behaviour first showed up when I switched from Visual Studio 2012 to 2013. Keep that last sentence in mind, as it's the main reason for this question. It feels like the version of VS should not affect this behaviour in any way whatsoever, since i'm still compiling against the same framework version.
The scenario I have is that i'm running ASP.NET WebForms and we're customizing the output of a specific ASP.NET control being rendered. Actually, it's a third-party control that we have an inheritence relationship with, where we customize the output from the control.
Here is the code in where the error happens (I slightly modified the source code in an attempt to better show you my points):
protected override void Render(HtmlTextWriter output)
{
using (var stream = new System.IO.MemoryStream())
{
using (var writer = new System.IO.StreamWriter(stream))
{
var htmlWriter = new HtmlTextWriter(writer);
base.Render(htmlWriter);
htmlWriter.Flush();
stream.Position = 0;
using (var reader = new System.IO.StreamReader(stream))
{
string content = reader.ReadToEnd();
// modify content...
output.Write(content);
reader.Close();
}
} // exception thrown
}
}
Here's the exception message:
Cannot access a closed Stream.
I do understand that the exception itself is being thrown, as is explained here: MemoryStream - Cannot access a closed Stream. In fact i'm very curious to know why this code have been working for such a long time. It's clearly pointed out by a number of different answers here on stackoverflow that this is not the proper way to handle streams. Here's another one.
If I compile this exact same code in Visual Studio 2012, it all "works", i.e. I do not get the exception. However, when compiling in VS 2013 I do get the exception.
If you've read this far you might also want to know my environment setup. These are the points I think might be worth for you to know in order to give any guidance.
- WebSite project
- Hosted locally in IIS 7.5
- Targets .NET 4.0
- Built in Debug mode using Any CPU
The actual question: How can the version of Visual Studio affect this behaviour?
Update1: Settings under Exceptions -> Common Language Runtime exceptions is set to 'User-unhandled' for both VS2012/13. 'Thrown' is unchecked.