Use of System.IO.Packaging is not server-safe


The BCL System.IO.Packaging uses IsolatedFileStorage when the zipped XLSX file exceeds some specific boundary (I've heard different stories of 1.3MB, 7MB, and 10MB). This presents a variety of issues when running under IIS, whether running under NetworkService or AppPoolIdentity. It's also not thread-safe.

I strongly recommend implementing an alternative packager using a compatible open-source ZIP library such as SharpZipLib or DotNetZip, otherwise people trying to use this to create sizable Excel files server-side are going to have numerous problems, as I've had recently.

As an aside, I'm currently trying out setting the legacyCasMode to True for my IIS application as a workaround, but I don't know yet if this has any effect. It's certainly not ideal.


JanKallman wrote Oct 23, 2012 at 5:21 PM

Yes, I'm award of this problem. I'm actually looking at using DotNetZip right now, but it's no easy fix, so it will not be implemented until the next version whenever that will be).

richardtallent wrote Oct 24, 2012 at 3:56 PM

I dug a little more and the issue is where SparseMemoryStream is instantiated within ZipIOFileItemStream with a highWaterMark argument of 10MB. No hope there of a workaround that I can see unless Microsoft fixes it.

But I did also find that the Mono project has an alternative implementation for System.IO.Packaging, and their libraries are also licensed under LGPL. Maybe it would be possible to simply include the appropriate bits from their library?


Or maybe replace all use of System.IO.Packaging with an Interface that could be implemented using either?

richardtallent wrote Oct 24, 2012 at 8:15 PM

In the meantime, for users using EPPlus under IIS who have a server environment where it is possible to do so, I may have found a workaround -- run the application pool under a new local user.

Regular users have isolated storage available to them, but it appears the automatic accounts created under AppPoolIdentity do not. Since switching, I haven't encountered the error (though it's been less than an hour).

I contacted the author of the Mono Packaging code, he also contributes to EPPlus. He says Mono's Packaging class may not be bug-free enough for use within EPPlus, but I think it's at least worth a shot, and as bugs are addressed, they can be fixed for Mono as well. Anything is better than starting from scratch on another OPC implementation.

JanKallman wrote Oct 26, 2012 at 2:13 PM

Thanks for the bump to fix this :). I have just checked in the new code where I have switched to DotNetZip.
Packaging is gone, hopefully for good.
Check it out under the CoreChanges bransch.

richardtallent wrote Oct 26, 2012 at 8:35 PM

Thanks for the quick work on this! I like how you made the Compression level public -- the Microsoft default deflate setting was not aggressive enough for the large workbooks I create.

I'd love to be able to test it -- any chance my pull request from back in August can get integrated into that branch as well so I can test in my environment?

AshishBhatnagar wrote Jan 4, 2013 at 6:24 AM

HI Rechard/Jan,
First of all thanks for your kind help all the time.

I would like to know that is the mentioned problem is resolved? I saw it is marked as fixed by Jan. Which version of the EPPLUS contains the fix?

I am going through the similer kind of problem. Please suggest if you have any work around avaialble for a quick fix.


rakeshgoel wrote Jan 30, 2013 at 10:00 AM

Hi Jan

I downloaded the latest stable version and generated a file with compressed size around 2MB. The IsolatedStorage is still getting used by the process.

You mentioned that you have replaced System.IO.Packaging with DotNetZip. Can you please confirm whether this has been done or is still pending.


JanKallman wrote Feb 5, 2013 at 6:01 AM

Yes, it will be a part of next version, if you want to try it, download this changeset (This is the version before i started to mess with the cellstore).

csarg21 wrote Feb 14, 2013 at 5:31 PM

Hi JanKallman, I've downloaded the code and I've tested the Packaging issue and I think that is fixed :D.
I had a problem when creating large excel files in SSIS. I tried the workarounds like creating an AppDomain, but it did not fix the issue, but now with the new DotNetZip packaging I don't have the IsolatedStorage Exception anymore
Great Job!!!!

amcgrath wrote Apr 16, 2013 at 2:35 PM

Hi there,

I'm currently using version 3.1.2 and experiencing the IsolatedStorage Exception when running more than one instance.

I've looked at the source code for version 3.1.3 and it still seems to use System.IO.Packaging where the changeset af16b68ec2e5 doesn't (in ExcelPackage.cs for example). I was just wondering if DotNetZip was used in the latest 3.1.3 release? If not, will it be used in the next one?


knippers wrote Apr 24, 2013 at 9:27 PM

Hi amcgrath,

I don't think the latest source contains the DotNetFix version, at least I couldn't find it either. The mentioned specific changeset does contain the new zip method.

For me the new zip method seems to work (tables, basic pivot, images). I had to make a code fix for hyperlinks with parameters (e.g. &name=value) in class ZipPackageRelationshipCollection, method WriteZip. Instead of just adding rel.TargetUri I had to escape it: SecurityElement.Escape(rel.TargetUri.ToString())

Now that it passed my basic tests I have to see if it fixes my really slow large excel file issue.

Question for JanKallman, any idea when the new zip method will start to appear in the default source tree?


richardtallent wrote Jul 23, 2013 at 3:18 PM

So... it's been 9 months, and it appears the default branch is still using System.IO.Packaging.

I really don't think think should be called "resolved" until it becomes part of a core version. The changes have been functioning perfectly for me, but I would definitely like to upgrade to apply the numerous bug fixes and new features that have been added since last October.

clively wrote Aug 16, 2013 at 4:05 PM

Still occurring in

When will this be folded into the main code base?

FoolishRaymond wrote Aug 21, 2013 at 11:12 AM

I have been using EPPlus for some time for reporting generation, in a multiprocess environment. I encountered this issue - System.ObjectDisposedException: Store must be open for this operation.

I tested the quick fix provided by Jan (thanks as always!), in af16b68ec2e5, and it solved my previous issue, but unfortunately this version contains a minor bug. In the class ZipPackageRelationshipCollection, the xml attribute value for rel in the method WriteZip needs to be escaped. Please consider this when putting this fix to the main branch.

Thank you Jan for the wonderful library!

tralal wrote Oct 1, 2013 at 8:51 PM

I still got an error in version 3.1.3 (resulting with HRESULT: 0x80070005 (E_ACCESSDENIED) )

However below steps have helped to me:

create new folder on server
C:\Documents and Settings\Default User\Local Settings\Application Data\IsolatedStorage
Allow read/write to Everyone


tonyqus wrote May 24, 2014 at 8:34 AM

Maybe you can replace System.Packaging with NPOI.OpenXml4Net

didar_uranov wrote Jun 20 at 5:44 AM

EPPlus has switched to DotnetZip in 4.0 Release. From changelog:

New features 4.0

Replaced Packaging API with DotNetZip
  • This will remove any problems with Isolated Storage and enable multithreading