MemoryStream кажется закрытым после NPOI workbook.write?

Обновление от 03.01.2020: Как указал Флориан Дендорфер, существует override, добавленный в октябре 2018 г. для предотвращения закрытия потока. Пожалуйста, сначала попробуйте перегрузку, прежде чем использовать этот обходной путь (и проголосуйте за ответ Флориана!)

Оставив оригинальный ответ для исторических целей.

Другой обходной путь к этой проблеме... который не использует несколько объектов MemoryStream.

Создайте класс NpoiMemoryStream, который наследует MemoryStream и переопределяет метод Close:

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();
    }
}

Затем используйте этот поток следующим образом:

var ms = new NpoiMemoryStream();
ms.AllowClose = false;
workbook.Write(ms);
ms.Flush();
ms.Seek(0, SeekOrigin.Begin);
ms.AllowClose = true;

В какой-то момент между сбросом и поиском NPOI попытается закрыть поток, но, поскольку мы переопределили Close(), а флаг AllowClose равен false, мы можем оставить поток открытым. Затем верните AllowClose значение true, чтобы обычные механизмы утилизации могли его закрыть.

Не поймите меня неправильно... это все еще хак, который не нужно реализовывать... но он немного чище с точки зрения использования памяти.

Не знаю, нужно ли это еще, но есть overload

Write(Stream stream, bool leaveOpen)

где, если вы установите leaveOpen = true, ваш MemoryStream останется открытым

Как указано выше alun, а также в этот вопрос, который вы можете передать потоку в другой MemoryStream:

...
MemoryStream ms = new MemoryStream();
using(MemoryStream tempStream = new MemoryStream)
{
    workbook.Write(tempStream);
    var byteArray = tempStream.ToArray();
    ms.Write(byteArray, 0, byteArray.Length);
    HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
    result.Content = new StreamContent(ms);
    result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
    result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");
    result.Content.Headers.ContentDisposition.FileName = string.Format("{0}.xlsx", dt.TableName);
    return result;
}

От необходимости делать это немного пахнет кодом. Однако это необходимо только при выводе файлов .xlsx из-за того, как сторонние библиотеки обрабатывают поток.

Я сталкивался с похожими проблемами с API, которые закрывают/удаляют потоки, которыми они не владеют. Я не знаком с NPOI, но предполагаю, что метод Write принимает Stream, а не MemoryStream. Если это так, вы можете создать класс-оболочку Stream, который перенаправляет все вызовы (чтение/запись/поиск и т. д.) во внутренний поток (в данном случае ваш MemoryStream), но не перенаправляет вызовы на закрытие/удаление. Передайте оболочку методу Write, когда он вернет, ваш MemoryStream должен содержать все содержимое и все еще быть «открытым».

Кроме того, вам, вероятно, потребуется ms.Seek(0, SeekOrigin.Begin). После вызова Write ваш поток памяти будет расположен в конце потока, поэтому, если вы попытаетесь прочитать из этой позиции, он окажется пустым.