Update 1/3/2020: As Florian Dendorfer pointed out, there is an override added in October 2018 to prevent the stream from closing. Please try the overload first before using this workaround (and upvote Florian’s answer!)
Leaving original answer for historical purposes.
Another workaround to this issue…which doesn’t use multiple MemoryStream
objects.
Create a NpoiMemoryStream
class that inherits MemoryStream
, and overrides the Close
method:
public class NpoiMemoryStream : MemoryStream
{
public NpoiMemoryStream()
{
// We always want to close streams by default to
// force the developer to make the conscious decision
// to disable it. Then, they're more apt to remember
// to re-enable it. The last thing you want is to
// enable memory leaks by default. ;-)
AllowClose = true;
}
public bool AllowClose { get; set; }
public override void Close()
{
if (AllowClose)
base.Close();
}
}
Then, use that stream like this:
var ms = new NpoiMemoryStream();
ms.AllowClose = false;
workbook.Write(ms);
ms.Flush();
ms.Seek(0, SeekOrigin.Begin);
ms.AllowClose = true;
At some point between the flush and seek, NPOI will attempt to close the stream, but since we overrode Close()
and the AllowClose
flag is false, we can keep the stream open. Then, set AllowClose
back to true so normal disposal mechanisms can close it.
Don’t get me wrong…this is still a hack that shouldn’t need to be implemented…but it’s a bit cleaner from a memory usage standpoint.