この他の質問でも詳しく説明したように、マニフェストファイルを使用して登録不要のCOMを実行します。
現在、プラグインをサポートするアプリケーションで登録不要のCOMを使用しようとしています。プラグインは、メインアプリケーションがすでにインストールされた後にメインアプリケーションのフォルダーに追加できるOCXファイルです。
ただし、これは、メインアプリケーションのマニフェストファイルにプラグインインストーラーによるパッチを適用する必要があることを意味します。これは、特に複数のプラグインをインストールできる場合は、危険でエラーが発生しやすいことのように思われます。
メインアプリケーションのマニフェストファイルを何らかの方法で分割して、各プラグインが独自の部分を個別のファイルとして安全に追加できるようにする方法はありますか？または、マニフェストファイルにパッチを適用する別の安全な方法はありますか？
関連する場合：wixを使用してインストーラーを作成します。
アプリケーションのマニフェスト ファイルを変更することはお勧めしません。それはかなり壊れやすいようで、書き込み可能な場所にある場合にのみ機能します。
プロセスの起動時に、アプリケーションのマニフェストを使用して、プロセス全体のアクティベーション コンテキストとしてプッシュされる「アクティベーション コンテキスト」が生成されます。ただし、各スレッドには、直接操作できるアクティベーション コンテキスト スタックもあります。特定のスレッドでの操作は、COM 登録データを探すときに、スタックの最上位のコンテキストとプロセス全体のアクティベーション コンテキストの両方を調べます。
プラグイン コードが COM を呼び出す必要があるときはいつでも、プラグイン固有のマニフェストをスレッドでアクティブにすることをお勧めします。これは、次の 2 つの方法のいずれかで最も簡単に実行できます。
プラグイン固有のマニフェストを ID2 マニフェストとしてプラグインに埋め込み、マクロISOLATION_AWARE_ENABLEDを定義してコンパイルします。これは基本的に、マニフェストからのコンテキストを必要とする一般的な Windows API をラップして、呼び出しに関する適切なアクティベーション コンテキストを自動的にアクティブ化および非アクティブ化します。
プラグインへのすべてのエントリ ポイントの周りのスレッドで、適切なアクティブ化コンテキストをアクティブ化/非アクティブ化します。これは、アクティベーション コンテキスト APIを通じて行われます。これは、アクティベーションコンテキスト管理オブジェクトを使用すると最も簡単に実行できます。
.Net を使用している場合は、この回答に示されているコードを使用して、アクティベーション コンテキストを処理できます。