tags:

views:

273

answers:

2

System Description

A plotting component that uses OOXML to generate a document.

Plotting component consists of several parts. All parts are written in C++ as exe + dll's, with the exception of the interface to the OOXML document. The latter component is a COM component that was created in C#/.NET. The main reason for this is that the .NET framework contains System.IO.Packaging. This is a very handy built-in facility for dealing with OOXML documents.

We create a document out of a template OOXML document where certain bits and pieces are replaced by their actual content.

One of these bits is an OLE Server component. Basically this is a binary segment within the OOXML file. For writing this binary segment, the Packaging component apparently uses isolated storage.

Problem

Writing a segment > 8MB results in an exception being thrown "Unable to determine the identity of the domain".

On the C++ side this exception contains the error ISS_E_ISOSTORE ( 0x80131450 ).

We have analyzed this and as far as we can tell, this is a security feature that prevents semi-untrusted third-party component from completely ruining your HD by writing immense files.

We have then tried a lot of things in the .NET/COM component ( creating custom AppDomains, setting Attributes for maximum permissivity, Creating our own Streams and passing those to the Packaging component ) but every time it resulted in the same exception being thrown.

What could we do to make this work?

Could it be that when the .NET component is instantiated as a COM component, its AppDomain is alway untrusted?

+1  A: 

You should change the title of that question since your problem is not OOXML related.

Other than that: what system are you working on that 8MB chunks of data result in the risk of totalling your hard drive?

xmjx
It isn't directly related to OOXML, but it keeps us from writing the OOXML we want, so in that respect it is related. I never said my system was totaled by an 8MB file, the .NET runtime security feature for isolated storage seems to think that is a good upper limit.
QBziZ
+2  A: 

You might try to unzip the package yourself (instead of using the .NET package API), write directly to the file which represents the binary segment and zip it again.

elbandido