0

ServicedComponentWindows Server 2003 上の IIS 6.0 の Web アプリケーションから継承し、これをサイド バイ サイド アセンブリとして使用しようとしているマネージ .Net COM+ コンポーネントがあります。

を使用してアセンブリ マニフェストを生成し、mt.exeこれをテスト コンソール アプリケーションのサイド バイ サイド モードで正常に実行しました。ただし、IIS に関しては機能していないように見え、マニフェストを読み取るのではなく、レジストリから COM+ アプリケーションを見つけようとします。

マニフェストは mt.exe -managedassemblyname:myassembly.dll -out:myassembly.manifest、それを使用して生成され、Web アプリケーションの仮想ディレクトリにコピーされます。を使用filemonすると、マニフェストが読み取られることさえないことが明らかになります!

.manifestファイルをディレクトリに移動するbinと、読み取られたように見えますが、同じ問題が発生します。

この作業に成功した人からの助けをいただければ幸いです。

4

1 に答える 1

0

「.manifest」で終わる外部マニフェストは、実行可能ファイルに対してのみ自動的に取得されます。そのため、マニフェストについて IIS または Windows に通知する必要があります。

おそらく、コンソール アプリケーションのテストでは、実行可能ファイルのマニフェストに関連情報への参照があるMyAssemblyか、関連情報が直接含まれています。

さて、ServicedComponentここではあまり詳しくないので、一般的な言葉で話します。

  1. を呼び出すすべてのソフトウェアを制御MyAssemblyできる場合は、最初に意図的にマニフェストに情報をロードし、その情報をスレッドでアクティブ化し、 を呼び出してMyAssembly、非アクティブ化できます。これは、この種のプラグイン アーキテクチャを満たす最良の方法です。親プロセスを汚染していないため、コードが実行されている間、コードが実行されているスレッドを構成するだけだからです。このアプローチは、アクティベーション コンテキスト API の呼び出しによって行われます。この API の優れた例は、All-in One Code Framework にバンドルされている reg-free COM サンプルにあります。
  2. 呼び出しているすべてのコードを制御できない場合MyAssembly(IIS によって自動的に呼び出されている場合)、またはコードがあまりにも多くの場所で呼び出されていて、上記の方法ではコストがかかりすぎる場合は、いつでもここで「ハックアラウンド」を試すことができます。IIS6.0 ワーカー プロセスの実行可能ファイルを取得し、マニフェストがある場合はそのマニフェストを編集するか、ない場合は新しいマニフェストを追加して (マニフェストが埋め込まれているかどうかを確認することを忘れないでください)、 に依存するようにしMyAssemblyます。このアプローチでは、MyAssemblyのマニフェスト コンテンツは基本的に、IIS6 内で実行されているすべてのコードの実行コンテキストの一部になるため、かなり負荷の高いアプローチです。
于 2011-01-10T09:55:03.967 に答える