NPOI workbook.write后MemoryStream似乎被关闭了？

Question

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

但是我从响应中什么都没有得到。这是我的代码：

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。

我做错了什么？

- fankt

---

NPOI的xlsx变体可以实现此操作，而另一个变体则不行。这只是该库的奇怪之处，有点糟糕。您可以通过执行ms.ToArray()并将其提供给新的MemoryStream来解决此问题，但这有点悲伤和浪费。 - alun

@alun 谢谢，它有效！但正如你所说，它真的很浪费...我会将其标记为解决方法，并查看是否可以在未来解决。再次感谢你。 - fankt

@alun 谢谢。我之前使用的是 stream.getbuffer() 生成了 xlsx 文件，但在 MS Excel 中出现了“...corrupt data...” 的错误提示。将 stream.getbuffer 更改为 ms.ToArray() 解决了这个问题。 - maddog

在我的情况下，Response.BinaryWrite(ms.ToArray()) 和 Response.ContentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" 解决了问题。请参见示例 http://goo.gl/m3xPa7。 - Brij

尝试设置： result.Content = new ByteArrayContent(ms.GetBuffer()); - Alex Nguyen

Answer 1

2020年1月3日更新：正如Florian Dendorfer所指出的那样，2018年10月添加了一个override来防止流关闭。请先尝试使用超载，然后再使用此解决方法（并点赞Florian的答案！）

为了历史记录而保留原始答案。

---

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

创建一个继承MemoryStream并重写Close方法的NpoiMemoryStream类：

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，以便正常的处理机制可以关闭它。

不要误解...这仍然是一个不应该实现的hack...但从内存使用的角度来看，它更加清晰。

- Joe the Coder

---

使用 ms.Flush() 的目的是什么？MSDN 在这里说：“重写 Stream.Flush() 方法，以便不执行任何操作。” 为什么“NPOI 将尝试关闭流”呢？既然我们只是写了一些数据并希望继续使用它，那么保持它打开不是更合理吗？ - alanextar

这真是美得令人作呕。非常感谢这个技巧。请不要删除这个回答，因为在Word文档中不存在负载过载问题，只存在于工作表中。 - Gaspa79

Answer 2

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

Write(Stream stream, bool leaveOpen)

如果您设置leaveOpen = true，则保持您的MemoryStream开放。

- Florian Dendorfer

---

这是对这个问题最明智的回答！ - Peter

仅适用于XSSFWorkbook。使用接口时，此方法不可用。 - gangfish

我并没有看到Write方法被如此重载，即使在XSSFWorkbook中也没有。 - papadi

@papadi，正如用户“gangfish”所提到的，您需要查看XSSFWorkBook以找到此重载。我最初也没有找到它，但后来我注意到我正在查看“POIXMLDocument”类，而不是XSSFWorkBook。 - Yash

Answer 3

正如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 文件时是必要的。

- Josh Stella

---

我必须说，我更喜欢这种解决方案，而不是覆盖类，因为它更加清晰。 - Daniel Mošmondor

这个解决方案不够简洁。在处理大文件时，它会在内存中复制整个文件内容。 - papadi

Answer 4

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

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

- MarkPflug

---

+1，这个方案效果很好，内存占用最小，并且在类似情况下可以重复使用。您可以覆盖和转发所有流方法（除了Close和Dispose - 将它们保留为空NO-OPs），只需编写几分钟的代码即可将其传递给“封装”的流。我把我的称为"NoCloseStream"，以便我知道它正在做什么。 - Bruce Pierson

对于直接使用NPOI的人来说，可能最好的方法是使用Write覆盖（如果存在），但我来到这里是因为基于NPOI的ExcelMapper也有同样的问题，而且没有覆盖。这个答案帮助我解决了ExcelMapper的问题。 - Milan