在 NPOI workbook.write 之后，MemoryStream 似乎已关闭？

Question

我在 ASP.NET Web API 项目中使用NPOI 将 DataTable 转换为 Excel。

但是我从回复中什么也没得到。这是我的代码：

public HttpResponseMessage GetExcelFromDataTable(DataTable dt)
{
    IWorkbook workbook = new XSSFWorkbook(); // create *.xlsx file, use HSSFWorkbook() for creating *.xls file.
    ISheet sheet1 = workbook.CreateSheet();
    IRow row1 = sheet1.CreateRow(0);
    for (int i = 0; dt.Columns.Count > i; i++)
    {
        row1.CreateCell(i).SetCellValue(dt.Columns[i].ColumnName);
    }

    for (int i = 0; dt.Rows.Count > i; i++)
    {
        IRow row = sheet1.CreateRow(i + 1);
        for (int j = 0; dt.Columns.Count > j; j++)
        {
            row.CreateCell(j).SetCellValue(dt.Rows[i][j].ToString());
        }
    }

    MemoryStream ms = new MemoryStream();
    workbook.Write(ms);
    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;
}

我在workbook.Write(ms) 之后设置了一个断点来检查ms.Length，但它返回一个异常：System.ObjectDisposedException。

我哪里做错了？

Answer 1

2020 年 1 月 3 日更新： 正如 Florian Dendorfer 指出的那样，2018 年 10 月添加了一个 override 以防止流关闭。请在使用此解决方法之前先尝试重载（并支持 Florian 的答案！）

出于历史目的留下原始答案。

---

此问题的另一种解决方法...不使用多个 MemoryStream 对象。

创建一个继承MemoryStream的NpoiMemoryStream类，并覆盖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 标志为假，我们可以保持流打开。然后，将AllowClose 设置回 true，以便正常的处理机制可以将其关闭。

不要误会我的意思...这仍然是一个不需要实施的 hack...但从内存使用的角度来看它更简洁。

Answer 2

我不知道这是否仍然需要，但有一个 overload

Write(Stream stream, bool leaveOpen)

如果您设置leaveOpen = true，则您的 MemoryStream 保持打开状态

Answer 3

如上所述alun 以及this 问题中，您可以将流馈送到另一个 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;
}

不得不这样做有一点代码味道。但是，由于涉及的第 3 方库处理流的方式，这仅在输出 .xlsx 文件时是必需的。

Answer 4

我遇到过关于关闭/释放流的 API 的类似问题 不拥有。我不熟悉 NPOI，但我假设 Write 方法接受 Stream，而不是 MemoryStream。如果是这种情况，您可以创建一个包装器 Stream 类，将所有调用（读/写/查找等）转发到内部流（在这种情况下为您的 MemoryStream），但不转发对关闭/处置的调用。将包装器传递给 Write 方法，当它返回时，您的 MemoryStream 应该包含所有内容并且仍然是“打开的”。

此外，您可能还需要ms.Seek(0, SeekOrigin.Begin)。在调用 Write 之后，您的内存流将位于流的末尾，因此如果您尝试从该位置读取，它将显示为 emtpy。