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.
Comments: Maybe you can replace System.Packaging with NPOI.OpenXml4Net
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.
Comments: Maybe you can replace System.Packaging with NPOI.OpenXml4Net