問題タブ [maf]

.NET アドイン フレームワークでは、ホスト側でアドイン dll の場所を取得できますか?

AddInToken には、dll の場所を含む _addin フィールドが含まれていますが、プライベートであるため取得できません。

アドイン フレームワークは初めてです。現在、UserControl を返す WPF アドインを作成しようとしています ( https://msdn.microsoft.com/en-us/library/bb909849(v=vs.110).aspxによると)。

問題は、アドインからユーザー コントロールを取得しようとすると、例外がスローされることです。

1. 最初の例外は、「'' という名前のリソースが見つかりません。リソース名は大文字と小文字が区別されます。」でした。すべてのリソースは別のライブラリに保存されており、MEF (MAF の前) で同じことを行ったときに正常に機能しました。

2. OK、UserControl からすべての StaticResources を削除したところ、別の例外が発生しました:「{"ファイルまたはアセンブリ 'Infralution.Localization.Wpf, PublicKeyToken=547ccae517a004b5' またはその依存関係の 1 つを読み込めませんでした。"}」。このライブラリはローカライズに使用されます。

注: 必要なすべてのライブラリは、アドインと同じフォルダーにあります。

アドイン参照ライブラリがロードされていませんか? または、どこを間違えたのですか？

プラグインのさまざまな程度の分離をサポートする必要があるシステムに取り組んでいます。MAF を選択したのは、私のニーズに一致し、個別のプロセス分離と AppDomain 分離をすぐにサポートできるためです。

以下のサンプルでは、​​個別のプロセス分離を使用しています。

ただし、ホストとプラグインの間で共有されるライブラリで MAF を機能させるには問題があります。私はプロジェクトを持っていると仮定しましょう（出力ディレクトリ付き）：

そして参考文献

これにより、各パイプライン ディレクトリに単一の dll を含むクリーンなビルドが得られます。すべて正常に動作し、パイプラインはビルドされ、有効で機能しています。

問題のあるものを追加するまで：

My.PlugIn.AddIn プロジェクトをパイプラインに含めることができないため、次の理由で問題が発生します。

1. My.PlugIn.AddIn の読み込み中に問題が発生しました - 依存関係 My.AddIn.Shared が見つかりません (AddInViews にアドイン ベースの単一の dll が含まれている場合)
2. IContract タイプに透過プロキシをキャストできません - (colyLocal=true で AddInViews に複数の dll が含まれている場合)

また、My.PlugIn.AddIn の単一のクラスのみに言及する価値があります。AddInBaseAttribute で装飾されており、共有アセンブリには単一のクラスがありません。

そのため、どちらの状況でもアドインをロードできません。イベントのカスタム ハンドラで問題を解決したかった

AddInStore.Rebuild を呼び出す前ですが、これはホスト アプリが実行しているドメインにのみ影響し、System.AddIn.Hosting.AddInStore によって内部的に作成されるドメイン「アドイン モデル検出ワーカー AD」には影響しません。

このクラスは静的であるため、ドメインの作成をオーバーライドする方法はありません。また、内部ドメイン解決エラーにアクセスできるようにするイベントも提供しません。カスタム アセンブリ解決ルールを挿入する方法や、内部の appDomain にメインの解決イベントを強制的に継承させる方法はありますか?

私はMAFを使用して、ユーザー/顧客にソフトウェアを強化する可能性を提供しています. アドインは制限された権限で実行され、アドインをサード パーティの開発者から購入した場合は、当社だけでなく顧客にとっても信頼できないコードになる可能性があります。

この場合、ホストとホスト側アダプターはメイン AppDomain で完全なアクセス許可で実行され、アドインとアドイン サイド アダプターはほとんどアクセス許可なしで実行されます。

AddInStore.FindAddIns を介してアドイン トークンを取得すると、アドイン アセンブリ自体が本来あるべきベンダーからのものであることのみを検証できます。攻撃者がアドイン アセンブリを交換した場合、そのことがわかり、そのアセンブリはアクティブ化されません。とにかく、それはほとんど許可なしで実行されるため、攻撃者はアプリケーションと環境 (ホスト、イントラネットなど) に実際に害を及ぼすことはできませんでした。

しかし、攻撃者がホスト側のアダプター アセンブリを置き換える可能性もあります。攻撃者は、新しいアセンブリを適切なフォルダーに配置するだけで済みます。これは完全な権限で実行されるため、攻撃者のコードはアプリケーションと環境に実際に損害を与える可能性があります。攻撃者はホストとアドインの間にいるため (多かれ少なかれ中間者)、両者の間で交換されるデータも変更できます。

コードをデバッグしてデバッガーでアドイン トークンをチェックすると、アドイン ストアがパイプラインを構築するために使用したさまざまなアセンブリへのすべてのパスを確認できます。

残念ながら、取得したアセンブリに関する重要な情報は非公開であり、アクセスできません。

この情報にアクセスするための回避策はありますか?

ホストからのサービスを使用するためにアドインがホスト システムへのコールバックにも使用できる MAF パイプラインを構築しています。これらのメソッドは、アドインで処理する必要がある例外をスローできます。その場合は、それらをキャッチするだけでなく、分析することも意味する必要があります。

いつものように、appdomain の境界を越えてオブジェクトを取得するには 2 つのオプションがあります: それらをシリアル化するか、MarshalbyRefObject.

実際、私は両方のオプションで問題を抱えています:

シリアル化を使用している場合、アドインは例外を逆シリアル化できないため、例外の正確な種類を知る必要があります。つまり、ここでは抽象化レイヤーで作業することはできません。Exception クラス自体はシリアル化可能としてマークされているため、これが機能するようにすべてのサブクラスもシリアル化可能としてマークする必要があります。ホストとアドインの間でタイプを分離できないため、これは実際には解決策ではありません (抽象化に取り組むことができないため)。

MarshalbyRefObject を使用しても機能しません。また、すべての Exception は「Exception」を拡張する必要があるため、MarshalbyRefObject を拡張することはできません。

この問題を解決できる標準パターンはありますか?