Possible Issue with Dispose on Xlsx reader.

[Stu Wilson]

We've got a simple Xlsx reader (same code for Xls)

                   XlsxReader reader = new XlsxReader(fullyQualifiedPath);

                   reader.CurrentSheet = 0;

                    while (reader.ReadRecord())

                    {

.. do stuff here

                    } 

which is appearing to throw an error when instantiating the XlsxReader.  Looking at the stack trace, everything looks OK, except when it's trying to Dispose, its already Disposed.

System.ObjectDisposedException: Can not access a closed Stream.

   at System.IO.Compression.DeflateStream.EnsureNotDisposed()

   at System.IO.Compression.DeflateStream.Flush()

   at MS.Internal.IO.Packaging.CompressStream.Flush()

   at MS.Internal.IO.Packaging.CompressStream.Dispose(Boolean disposing)

   at System.IO.Stream.Close()

   at MS.Internal.IO.Zip.ZipIOLocalFileBlock.Dispose(Boolean disposing)

   at MS.Internal.IO.Zip.ZipIOLocalFileBlock.Dispose()

   at MS.Internal.IO.Zip.ZipIOBlockManager.Dispose(Boolean disposing)

   at MS.Internal.IO.Zip.ZipIOBlockManager.Dispose()

   at MS.Internal.IO.Zip.ZipArchive.Dispose(Boolean disposing)

   At MS.Internal.IO.Zip.ZipArchive.Dispose()

   At DataStreams.Xlsx.Zip.ZipArchive.Dispose()

   at DataStreams.Xlsx.OOXml.Read.Workbook..ctor(Stream data)

   at DataStreams.Xlsx.XlsxReader..ctor(String fileName)

We are using 5.20.0.0 (.Net4.5)

Thx

Stu

[shriop]

Can you try to recreate using v5.22 demo from the site? v5.20 was the first version where I reworked the Zip implementation and there was some funkiness that I've hopefully resolved, but maybe made it into a release before I handled it.

Bruce Dunwiddie

[Stu Wilson]

So...

We did finally get to the bottom of this and it's related to Windows' own management of a folder called IsolatedStorage

Basically when dealing with XLSX files, those being a compressed folder containing multiple files, Windows is using the IsolatedStorage folder to perform compression and decompression activities under the hood.  The issue we were seeing is that the user under which our console application was running did not have it's own folder, and did not have permissions to write to the Default User's location

For us, the issue was compounded because it worked quite happily under the web application front end, but failed on the console end, even if both the Application pool and the user under which the console application was running were the exact same user, and both applications were running on the same server.

The simplest way to get round this was to ensure that this directory exists for your application user 

C:\Users\USER_NAME\AppData\Local\IsolatedStorage

Here are a couple of threads that I found that had similar issues, both using Zip compression/decompression

http://www.gemboxsoftware.com/support-center/kb/articles/23-isolatedstorageexception-when-writing-a-large-xslx-files (For later version of Windows the location would be C:\User\Default\AppData\Local\IsolatedStorage

http://help.octopusdeploy.com/discussions/problems/34714-can-not-access-a-closed-stream

Hope this helps anyone who gets this in the future.

Stu