マネージドDLLをアンマネージC++プロジェクトに依存するように追加

Question

マネージドB.dllとC.dllに依存するマネージDLL A.dllを持つプロジェクトがあります。

私はCOMインターフェイス経由でアンマネージドC++プロジェクトDにA.DLLを公開します。すべて正常です...しかし、A.DLLはD.dllとC.dllを見つけることができず、適切な例外が発生します。私は同じフォルダに入れてみましたが、うまくいきません。これらの依存関係をどのように、どこで参照する必要がありますか？

C++では、静的リンクを使用してA.dllを作成するだけですが、.NETにはこのオプションはありません。

更新： .exeファイルと同じディレクトリにライブラリを置くと、バイナリが失われました。

Answer 1

通常のCLR検索ルールがここに適用されます。最初にGACを探し、次にEXEがあるディレクトリを探します。登録からA.dllを見つけるようにCOMランタイムを納得させることができます。Regasm.exe/codebaseオプションを使用するとどこにでも保存することができます。しかし、ではなく、は、CLRが依存関係を探す場所に影響します.EXEの場所のみを考慮します。

この問題を解決するには、Fuslogvw.exeユーティリティを使用します。

代替案は一般的に面倒です。 A.dllに[ComVisible]型があり、最初にインスタンス化されることが保証されている（「アプリケーション」と考える）限り、CLRが他のDLLを見つけるのを助けるために、コンストラクタ内のAppDomain.CurrentDomain.AssemblyResolveイベントをサブスクライブできます。しかし、コンストラクタがBまたはCの型を必要としないことは非常に重要です。ジッタがコンストラクタをコンパイルする必要がある場合、クラッシュします。

これは適切なオプションではない場合、appname.exe.configファイルを作成することは、EXEインストールディレクトリのサブディレクトリにDLLを展開することをお勧めする場合には、いくらか役に立ちます。しかし、通常はEXEを制御していないので、通常は他の人の責任であるため、これはCOMシナリオではまれなことです。コードをテストするときは、ローカルにデプロイすることをお勧めします。本番環境では、GACを真剣に検討する必要があります。とにかくCOMの良いアイデアは、登録以来、それは強力なDLL地獄の頭痛を与えるマシングローバルです。