アセンブリが同じディレクトリにあるにもかかわらず、アセンブリ参照が見つかりません

Question

現在、一部のソフトウェア用のアドインを開発しています。アプリケーションは一部の母国語で書かれているにもかかわらず、.NETで開発することにしました。 .NETで外部インターフェイスを直接作成するいくつかの問題があるため、C ++/CLIでブリッジDLLを構築することにしました。

アドイン.iniファイルでは、C ++/CLI DLLが名前で参照されるため、アプリケーションはそこからロードされます。ただし、.NET DLLは、C ++/CLI DLLから参照されているだけで、エクスポートされたタイプが利用可能です。このセットアップでは、Howerverでは、アプリケーションが.NET DLLをロードしてクラッシュします。

私たちはすぐに、 AppDomain.AssemblyResolve C ++/CLI DLLがあるのと同じディレクトリから.NETアセンブリをロードするイベントであるため、問題自体が解決されます。

実際の質問は、アセンブリが参照するアセンブリと同じディレクトリにあるのに、なぜローダーが.NET DLLを見つけられないのですか？ロードアセンブリは、現在の作業ディレクトリだけでなく、まず同じディレクトリを検討することを常に期待していました。それが作業ディレクトリを変更した場合、実行可能ファイルはなぜアセンブリを見つけるのですか？または、CLRがC ++/CLIアセンブリをロードして（純粋な管理アプリケーションではなく）呼び出すことで呼び出された場合、事態は異なりますか？

Answer 1

使用することをお勧めします fuslogvw.exe この種の問題を分析するには：

fuslogvw.exeおよび診断.NETアセンブリの結合問題

そして、もちろん、ファイルが見つからないファイルで問題を分析するための汎用ツール：

プロセスモニター

Answer 2

アセンブリの調査パスは、管理されていないEXEがプロセスを開始すると、少し予測不可能になります。おそらくLoadLibraryまたはsetDlldirectoryを介してC ++/CLI DLLをロードしたからといって、 いいえ 何らかの形で、CLRのプロービングパスに影響します。

しかし、それはただ推測しています。 fuslogvw.exeによって生成された出力を見るとき、推測する必要はありません。何が調査されているか、どのポリシーが適用されているかを正確に示します。 app.exe.configファイル（プロービング要素）または実際にAssemblyResolveで問題を修正します。