1

MEF ユーザーの通常の問題とは対照的に、私は、MEF で読み込んだアセンブリの依存関係が解決されない理由を理解しようとはしていません。私は反対の問題を解決しています - 依存関係ロードされている理由を見つけようとしています。

状況は、MEF を使用してアプリケーション ディレクトリの外部にある拡張アセンブリを動的に読み込む ASP.NET アプリケーションを使用している場合です。MEF で調べた異なるディレクトリに同じ拡張機能アセンブリの複数のバージョンが存在する可能性があり、それぞれに独自の依存関係セットがあり、これらの依存関係も単一のアセンブリの複数のバージョンである可能性があります (つまり、拡張機能A.dll、1.0.0.0には依存関係があります)。 D.dll, 1.0.0.0と拡張子B.dll, 2.0.0.0には依存関係D.dll, 2.0.0.0があります)。

すべての拡張機能とそのすべての依存関係が正しく読み込まれるという意味で機能します。理由はわかりません。ファイルに特別な設定はありませんweb.configアセンブリ解決に関する公式ドキュメントのどこで、それが機能するはずだと言っていますか? 要求しているアセンブリが置かれているのと同じディレクトリを見ることについては何も言いません。

ランタイムが依存関係を見つける方法を Fusion Log Viewer が教えてくれることを期待していましたが、特定の依存関係のすべての異なるバージョンのバインド要求が表示されていても、それをクリックして完全なログを表示すると、失敗したとしか表示されません。 bindings (はい、失敗したものだけでなく、すべての binding requests をログに記録するように設定しています)。

このシナリオが機能する理由を説明する公式ドキュメントの一部を教えてもらえますか?

4

1 に答える 1

1

MEF の主な解像度は、ComposablePartCatalog使用されているものによって決まります。たとえば、 を使用するDirectoryCatalogと、指定したディレクトリ内のすべてのアセンブリがプローブされて検出されます。

CompositionContainerを参照すると、配置されているカタログを見つけることができます。これにより、パーツが適切に構成されている理由に関する詳細が提供されます。

"Other Locations Probed"で定義されているルールにより、依存関係が検出されている可能性もあります。

アセンブリが LoadFrom メソッドを使用して別のアセンブリを参照する場合、呼び出し元のアセンブリの場所は、参照されているアセンブリの場所に関するヒントと見なされます。一致が見つかった場合、そのアセンブリが読み込まれます。


を使用しDirectoryCatalogてディレクトリ内のアセンブリを検索している場合、そのフォルダー内のすべてのアセンブリが内部的に読み込まれます。DirectoryCatalogこれにより、が構築されるときに、すべての依存関係もプロセスに読み込まれます。

于 2013-10-25T17:10:25.937 に答える