MEF環境でのアセンブリの依存関係の修復

Question

MEFを使用して拡張アセンブリを動的にロードするアプリケーションがあります。 1つのアセンブリはドメインレイヤーであり、2つ目はビューです。ドメインアセンブリが読み込まれ、正常に動作します。

• ソリューション私が午前問題は、ビューアセンブリは1..Nが含まれていることである
  • ドメインプロジェクト
  • ビュープロジェクト

：擬似構造は次のようになります最初のアセンブリのドメインオブジェクトのビジュアルプロキシであるユーザーコントロール。これにより、ドメインアセンブリに依存する点でビューアセンブリに制約が課されます。例えば上から見ると、View ProjectアセンブリはDomain Projectアセンブリに依存します。ビジョン・プロキシーをビュー・プロジェクトからドメイン・プロジェクトに移動すると問題は解決しますが、それは懸念の分離につながると私は思っています。

ビューアセンブリでAssembly.LoadFile（）メソッドを呼び出すと、標準のFileNotFoundExceptionが表示されます。これは、アプリケーションが実行されているルートの外側にドメインレイヤアセンブリが最初にロードされ、プローブパス内に存在しないためです。このプロセスの中で私が望んでいたのは、コアアセンブリがすでにロードされていて、ビューアセンブリがその依存関係を満たしていたためです。残念ながら、これはそうではありませんでした。

AppDomainSetup.PrivateBinPathは私にとってはオプションではありません。これは、アプリケーションをインストールしたファイル構造内にインストールするために拡張開発者に制約を課し、汚染を引き起こし、これは私たちが必要とするものではありません。私は、このタスクがインストールされたアプリケーションルートの下に単一のExtensionsディレクトリを持つことがどれほど簡単かを知っています。

私がしたいのは、アセンブリを読み込んで、すでに読み込まれてAggregateCatalogに追加されている他のアセンブリによってその依存関係が満たされるようにすることです。

誰も私の目標を達成するのに役立つ考え、示唆、助言をお持ちですか？

Answer 1

私の解決策は、module initialization through assembly injectionを使用しないことでした。非常に巧妙ですが、C＃からアセンブリをロードするときにフレームワーク4のために呼び出されることはありません。それは他の状況下で動作するかもしれません。

解決策は、基本に戻り、現在のAppDomainのAssemblyResolveイベントに依存することでした。まず、私の拡張機能のComposablePartCatalogを構築しているうちに、私は拡張機能のパスをコレクションに保存しました。アセンブリのロードが失敗すると、AssemblyResolveイベントが発生し、拡張モジュールの依存関係を探す拡張パスのコレクションを繰り返し処理します。

これは、インストールされたアプリケーションとインストールされている拡張機能の分離を維持するという私の目標に合っています。