we used Infragistiscs.Documents.Excel.worksheet DLL to load the excel file, The normal functionality works fine, but while we run through unit test cases like mocking, a exception is thrown, "Unable to determine the domain of the caller" isolated storage file exception
Workbook.Load(string filename)
This exception happened after we upgraded into infragistics 9.2 to 11.1
Hello Pradeep,
This exception has been seen once before with an OpenEdge project.
What we had determined is that the zip support we use for non-SL assemblies uses the ZipPackage class introduced in .NET 3.0. When we are writing to the individual files that will be zipped and the file contents grows larger than 8MB, the ZipPackage infrastructure converts its internal memory stream to a stream written to isolated storage so the file doesn’t have to remain in memory anymore. However, this requires permissions which are determined by the AppDomain in which the .NET Application is running. If no security evidence is supplied, trying to convert these zip file streams throws an IsolatedStorageException which says “Unable to determine the identity of domain.”
The following blog post about this is explains this: http://www.lyquidity.com/devblog/?p=65
Since this is a general .NET issue and not Infragistics specific, you might want to try asking your question on the MSDN forums as well.
Here are the AppDomain.CreateDomain methods which take an Evidence instance:
http://msdn.microsoft.com/en-us/library/8dba63a0.aspx http://msdn.microsoft.com/en-us/library/aehss7y0.aspx http://msdn.microsoft.com/en-us/library/ms130766.aspx http://msdn.microsoft.com/en-us/library/asd6fby4.aspx http://msdn.microsoft.com/en-us/library/hysz1834.aspx
I recommend first that you upgrade to the latest version of Infragistics that you can install as trial and test with. I would like to know whether or not the behavior persists with out latest version since improvements have been made over the years. Keep in mind that versions 9.2 - 11.1 are not longer supported and maintained. If the issue can be reproduced in the latest version of ours please attach a sample here to this thread.
Please let me know if you have any questions regarding this matter.
I'm seeing this same message "Unable to determine the domain of the caller" in 2014.1 v2108. Is this still an issue in 14.2 or later releases? Is there a workaround in 2014.1?
I'm using the InfragisticsWPF4.Documents.Excel interface to create and save a workbook to disk. All of this code should be running in the same AppDomain the rest of the app, correct? The lyquidity link discusses a case where code is running in an Excel Add-In or a COM object. I'm my case, I'm running managed C++ code making direct calls to the Infragistics API. Why would that require a different AppDomain? If it does require a different AppDomain, can't you supply security evidence to the ZipPackage API so that it's transparent to me as the caller?
Just checking. Can anyone give an update on this? thanks.
I upgraded to 2015.1, and I still get this error for very large Excel files. My test case has 271K rows and 12 columns.
Hello Kobie,
Thank you for posting in our forum.
As Michael has explained in his post aove this is how .NET zip packaging is working. So this is not an Infragistics issue but general .NET one. It seems that what you need is either to adjust the evidence used when creating the appdomain you are running this code within or to create a new appdomain with the required evidence and execute your code within that. Please follow the next link where similar issue were discussed and some workarounds were suggested http://rekiwi.blogspot.com/2008/12/unable-to-determine-identity-of-domain.html .
Thank you for using Infragistics controls.