1

次のフォルダー構造を持つアプリケーションがあります。

Application\Modules\XXX

もちろん、XXX 内のアセンブリは、XXX 内の他のアセンブリを検索します。

この問題は、リフレクションを使用してインスタンス化されたいくつかのインスタンスで発生します。

TProvider providerInstance = (TProvider)Activator.CreateInstance(providerType));

TProvider には、別のアセンブリ (XXX にも格納されている) で定義されたクラスを返すメソッドがあります。参照をロードする必要がある providerInstance のメソッドを呼び出すと、依存関係が同じ XXX フォルダーにある場合でも、依存アセンブリが見つからないという FileNotFoundException が発生します。

Fusion ログを見ると、アセンブリ ローダーは XXX ではなく、アプリケーション フォルダーのみをチェックしています ...

なぜこれが起こるのか、それを修正する方法について何か考えはありますか?

ありがとう。

4

3 に答える 3

3

その理由は、LoadFileメソッドを使用してアセンブリをロードしているためです。

LoadFile はファイルを LoadFrom コンテキストにロードせず、Lo​​adFromメソッドのようにロード パスを使用して依存関係を解決しません。

メソッドとコンテキストからのロードを使用するLoadFromか、可能であれば、Loadコンテキストを使用してロードする必要があります。

于 2013-07-19T10:32:14.990 に答える
2

Assembly.LoadFile(filename) でそれらをロードしています

これはよくある間違いです。LoadFile() だけがまともな MSDN の記事を持っていて、gobbledegook のように読めないため、頻繁に作成されます。ローディング コンテキストは .NET では非常に抽象的な概念です。

LoadFile() は、意図的に依存アセンブリを見つけたくない場合にのみ使用してください。これは非常にまれですが、アセンブリの検査などを行うプログラムのみがそうします。逆アセンブラのようなツール。

LoadFrom() は、CLR が依存アセンブリのディレクトリも参照できるようにするために必要です。一般に、これは DLL Hell の保証された修正ではないことに注意してください。型の ID には、元のアセンブリが含まれます。同じ名前空間名と型名を持つ型が複数のアセンブリに存在すると、問題が発生します。別のディレクトリにあるアセンブリのグループで発生する可能性が高い障害モード。特に、プラグイン シナリオのように、コンテンツを制御しない場合。InvalidCastExceptions を誤解させることは、次の宿敵となる可能性があります。これは、LoadFile() で読み込まれたアセンブリの非常に一般的な障害モードでもあります。プログラマーは、ファイルをディレクトリに整理するのが好きです。これは、職業上の責任であり、CLR が DLL Hell を回避する方法とはかなり相容れない OCD のようなものです。

于 2013-07-19T11:11:13.840 に答える