MemoryStream似乎在NPOI workbook.write之后关闭
本文关键字:write 之后 workbook NPOI MemoryStream | 更新日期: 2023-09-27 17:57:24
我正在使用NPOI在 ASP.NET Web API项目中将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
。
我哪里做错了?
2020 年 1 月 3 日更新:正如 Florian Dendorfer 指出的那样,2018 年 10 月添加了覆盖以防止流关闭。 在使用此解决方法之前,请先尝试重载(并对弗洛里安的答案投赞成票!
出于历史目的留下原始答案。
此问题的另一种解决方法...不使用多个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
标志为假,因此我们可以保持流打开。 然后,将AllowClose
设置回 true,以便正常的处置机制可以关闭它。
不要误会我的意思...这仍然是一个不应该实施的黑客......但从内存使用的角度来看,它更干净一些。
这是否仍然需要,但有一个overload
Write(Stream stream, bool leaveOpen)
其中,如果您设置了leaveOpen = true
,则使内存流保持打开状态
如上所述,在这个问题中,您可以将流馈送到另一个 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)
.在调用写入之后,您的内存流将位于流的末尾,因此如果您尝试从该位置读取,它将显示为emtpy。