Hi,
I did a little more research and this error message does not appear to be related to the UltraGridExcelExporter directly. It seems to be an issue with the DotNet framework and the ZIP packaging.
I found a couple of articles that might help. The articles seem to indicate that this error message is related to either the application domain identity and/or permissions. And it only happens with very large files (which makes sense since you are exporting such a large number of rows and columns).
Since no other customers have reported this issue, and plenty of people are exporting very large grids, my guess is that you are doing something unusual with your AppDomain or permissions and that's causing the issue.
Here's a couple of links I found that may help you track down the issue or work around it:
https://connect.microsoft.com/SQLServer/feedback/details/764356/subscription-fails-due-to-error-system-io-isolatedstorage-isolatedstorageexception-unable-to-determine-the-identity-of-domain
http://stackoverflow.com/questions/7488442/epplus-2-9-0-1-throws-system-io-isolatedstorage-isolatedstorageexception-when-tr
Hi Mike
Thanks for the articles.
The application is quite complex and is part of an Office Com AddIn, resulting in the UltraGrid export happening deep inside many nested levels of containership.
We used our data in the sample project that you provided and the export ran without errors. In this regard, simplistic "Hello World" type of projects generally do not stress the AppDomain sufficiently to flush out all weaknesses.
We will pursue this issue further, maybe trying to move the export higher up the containership chain, and will report back any sollutions
Thanks for your efforts thus far.
Best Regards
Ah, that makes sense, then. I don't know if you even have the ability to alter the permissions or identity in that case.
If you look at the first link I sent you, there's a Workaround section which uses a FileStream. You might try that and see if it works. You can export the grid using a FileStream instead of passing in a file name.
I don't really have any other good ideas. Except that I noticed some of the articles claim that the problem only occurs when the file is of a certain size. So one other potential alternative would be for you to limit the size of the files you are exporting. You could, for example, break up the grid into smaller grid, each with a sub-section of the data. That's probably not a good solution for your app, but it's something to consider as a possible last resort.
Frankly, exporting such a large excel sheet probably isn't all that useful to a user, anyway. No human user could possibly work with such a large set of data, so maybe presenting the user with smaller chunks of the data at one time would be feasible.
Tried the FileStream option, unfortunately no cigar there.
Further research shows that this CLR related error has been around since 2008, so no point in ringing Microsofts bell for this one.
Your second article from http://stackoverflow.com proposes delegating the export process to a sepperate .dll which our application could then load into a new and separate AppDomain and from which the export process could be run.
From our side this would involve re architecting our application as follows:
1) Extract the Ultra grid and it's related application functionality into a separate UltraGridApp.dll and re incorporate it back into the main application.
2) Then, when exporting to Excel: a) Load the UltraGridApp.dll into a new AppDomain b) Get the new AppDomain to load the necessary data c) Serialise the UltraGrid in the main application and pass that to the new AppDomain to configure itself before the export d) Run the export process from the new AppDomain
This proposed solution would require a lot more than a few days work, with no guarantee of success at the end.
So if you have any other ideas before we embark on that journey, they would be most appreciated.