0

MEFを使用して拡張アセンブリを動的にロードするアプリケーションがあります。1つのアセンブリはドメインレイヤーで、2つ目はビューです。ドメインアセンブリが読み込まれ、期待どおりに機能します。疑似構造は次のようになります。

  • 解決
    • ドメインプロジェクト
    • プロジェクトを見る

私が抱えている問題は、ビューアセンブリに、最初のアセンブリのドメインオブジェクトのビジュアルプロキシである1..Nユーザーコントロールが含まれていることです。これにより、ドメインレイヤーアセンブリに依存するという点で、ビューアセンブリに制約が課せられます。たとえば、上から見ると、ViewProjectアセンブリはDomainProjectアセンブリに依存しています。ビュープロジェクトからドメインプロジェクトにビジュアルプロキシを移動することで問題は解決すると思いますが、関心の分離に反することになります。

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

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

私がやりたいのは、アセンブリをロードし、それらの依存関係を、すでにロードされてAggregateCatalogに追加されている他のアセンブリと一致させることです。

私の目標を達成するのに役立つ考え、提案、アドバイスはありますか？

4

1 に答える 1

1

さて、私にとっての解決策は、アセンブリインジェクションによるモジュールの初期化を使用しないことでした。非常に独創的ですが、C＃からアセンブリをロードするときに、フレームワーク4に対してまったく呼び出されないようです。他の状況でも機能する可能性があります。

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

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

于 2012-01-10T02:51:38.170 に答える