OOXMLで大きなバイナリセグメントを使用する際の問題

Question

システムの説明

OOXMLを使用してドキュメントを生成するプロットコンポーネント。

プロットコンポーネントは、いくつかの部分で構成されています。 OOXMLドキュメントへのインターフェースを除き、すべての部分はC ++でexe + dllとして記述されています。 後者のコンポーネントは、C＃/。NETで作成されたCOMコンポーネントです。この主な理由は、.NETフレームワークに System.IO.Packaging が含まれていることです。これは、OOXMLドキュメントを処理するための非常に便利な組み込み機能です。

テンプレートOOXMLドキュメントからドキュメントを作成し、特定の断片を実際のコンテンツに置き換えます。

これらのビットの1つはOLEサーバーコンポーネントです。基本的に、これはOOXMLファイル内のバイナリセグメントです。このバイナリセグメントを記述するために、パッケージングコンポーネントは明らかに分離ストレージを使用します。

問題

セグメントの作成＆gt; 8MBの場合、「ドメインのIDを特定できません」という例外がスローされます。

C ++側では、この例外にエラーISS_E_ISOSTORE（0x80131450）が含まれています。

これを分析しましたが、わかる限りでは、これは巨大なファイルを書き込むことで半信頼できないサードパーティコンポーネントがHDを完全に破壊することを防ぐセキュリティ機能です。

.NET / COMコンポーネントで多くのことを試してみました（カスタムAppDomainの作成、最大許容度の属性の設定、独自のストリームの作成とパッケージ化コンポーネントへの受け渡し）が、毎回同じ例外が発生しましたスローされます。

この機能を実現するにはどうすればよいですか？

.NETコンポーネントがCOMコンポーネントとしてインスタンス化されると、そのAppDomainは常に信頼されないということでしょうか？

Answer 1

（。NETパッケージAPIを使用する代わりに）自分でパッケージを解凍し、バイナリセグメントを表すファイルに直接書き込み、再度圧縮しようとする場合があります。

Answer 2

問題はOOXML関連ではないため、その質問のタイトルを変更する必要があります。

それ以外：その8MBのデータチャンクで作業しているシステムは、ハードドライブを合計するリスクになりますか？