There is a high priority report we are creating that keeps getting an OutOfMemoryException.
The exception occurs after the report is created and formatting is applied and while the report is being saved.
It doesn't matter whether it is saved to MemoryStream or to a file.
I created a sample console application that can reproduce the problem.
It is being built with VisualStudio 2010 and uses ClosedXml.dll version 0.69.1.0.
I am running on a Windows 7, 64 bit machine with 8GB memory.
The sample application creates a report out of 164,000 custom objects where each object is identical and contains 19 properties. So the finished Excel file would have 164,000 rows, plus the heading row, and 19 columns. When the console application is run from the command line the user can specify how many rows to create. What is interesting is that sometimes it will throw the OutOfMemoryException and sometimes it will go to completion.
The sample application uses identical data in every row, so Excel's string sharing algorithm should conserve a lot of space, but for some reason ClosedXML keeps bombing out.
A lot of people have mentioned the same problem, but I think this is the first time anyone submitted a sample application to test with.
My workaround is to use Aspose.Cells for .Net in place of ClosedXML and Aspose has no problem saving the file, but ClosedXML throws an exception on the same data.
I much prefer the object model used by ClosedXML, but I have to use Aspose.Cells unless this can be fixed.
Thank you.
The exception occurs after the report is created and formatting is applied and while the report is being saved.
It doesn't matter whether it is saved to MemoryStream or to a file.
I created a sample console application that can reproduce the problem.
It is being built with VisualStudio 2010 and uses ClosedXml.dll version 0.69.1.0.
I am running on a Windows 7, 64 bit machine with 8GB memory.
The sample application creates a report out of 164,000 custom objects where each object is identical and contains 19 properties. So the finished Excel file would have 164,000 rows, plus the heading row, and 19 columns. When the console application is run from the command line the user can specify how many rows to create. What is interesting is that sometimes it will throw the OutOfMemoryException and sometimes it will go to completion.
The sample application uses identical data in every row, so Excel's string sharing algorithm should conserve a lot of space, but for some reason ClosedXML keeps bombing out.
A lot of people have mentioned the same problem, but I think this is the first time anyone submitted a sample application to test with.
My workaround is to use Aspose.Cells for .Net in place of ClosedXML and Aspose has no problem saving the file, but ClosedXML throws an exception on the same data.
I much prefer the object model used by ClosedXML, but I have to use Aspose.Cells unless this can be fixed.
Thank you.