0

現在、一部のソフトウェアのアドインを開発中です。アプリケーションは母国語で書かれていますが、.NET で開発することにしました。.NET で外部インターフェイスを直接作成する際にいくつかの問題があったため、C++/CLI でブリッジ DLL を作成することにしました。これにより、基本的な初期化が行われ、マネージ アセンブリが読み込まれ、そこからユーザー コントロールが作成されます。

アドイン .ini ファイルでは、C++/CLI DLL が名前で参照されるため、アプリケーションはそこからロードします。ただし、.NET DLL は C++/CLI DLL から (マネージ参照として) 参照されるだけなので、エクスポートされた型を使用できます。ただし、このセットアップでは、.NET DLL のロード中にアプリケーションがクラッシュします。

イベントをサブスクライブするだけで、C++/CLI DLL と同じディレクトリから .NET アセンブリをロードできることがすぐにわかったAppDomain.AssemblyResolveので、問題自体は解決されました。

実際の問題は、.NET DLL が参照しているアセンブリと同じディレクトリにあるにもかかわらず、ローダーが .NET DLL を見つけられないのはなぜですか? アセンブリをロードすると、現在の作業ディレクトリだけでなく、最初に同じディレクトリが検索されると常に思っていました。作業ディレクトリを変更すると、実行可能ファイルがアセンブリを見つけるのはなぜですか? それとも、(純粋なマネージド アプリケーションではなく) C++/CLI アセンブリを読み込むことによって CLR が呼び出された場合、状況は異なりますか?

4

2 に答える 2

4

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

Fuslogvw.exe と .NET アセンブリ バインドの問題の診断

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

プロセスモニター

于 2010-09-21T15:46:56.703 に答える
1

アンマネージ EXE がプロセスを開始すると、アセンブリのプローブ パスが少し予測不能になります。おそらく LoadLibrary または SetDllDirectory を介して C++/CLI DLL をロードしたからといって、CLR のプローブ パスにはまったく影響しません。

しかし、それは単なる推測です。Fuslogvw.exe によって生成された出力を見て、推測する必要はありません。何が調査され、どのポリシーが適用されているかを正確に示します。app.exe.config ファイル (プローブ要素) または AssemblyResolve を使用して問題を修正します。

于 2010-09-21T15:51:37.937 に答える