1

私のプロジェクトは、私の制御下にないホスト実行可能ファイルによってロードされるプラグイン（Windows DLL）です。私のDLLはいくつかの追加のライブラリをロードしたいと思っています。私はこれをプライベートアセンブリで行います。Win32 Appプラグインがこれを行う方法について、独自のディレクトリにDLLをロードする方法については素晴らしい答えがあります。しかし、/delayload dependentlib.dll必要になるまでアセンブリをロードしないようにメインDLLのリンク行を追加すると（さまざまな理由でこれを実行する必要があります）、Windowsはプライベートアセンブリを検索しなくなります-コンパイルしたマニフェストを無視するようです。代わりに通常の検索パスで遅延ロードされたDLLを探します。（これを確認するには、sysinternals procmonを使用します。）

これは既知のバグですか、それともアセンブリを遅延ロードする他の方法はありますか？依存ライブラリで気になるすべてのシンボルを知る必要があるLoadLibrary+GetProcAddressルートには行きたくありません。

4

2 に答える 2

1

ここでの問題は、遅延ロードされた関数への最初の呼び出しが行われたときに、アプリケーションのデフォルトのアクティブ化コンテキストが現在のコンテキストになることです。

あなたがする必要があるのは、アクティブ化コンテキストを作成することです: CreateActCtxは、独自のマニフェストを指しています (ヒンインスタンス + リソース ID が可能だと思います)。

次に、 ActivateActCtx (および対応する非アクティブ化関数) を使用して dll へのすべての呼び出し、または少なくとも最初の呼び出しをラップし、正しいアセンブリが検索されるようにします。

理論的には、delayloadヘルパー関数で適切なコンテキストをアクティブにするコードを埋め込むことができます。

于 2011-02-16T15:15:46.353 に答える
0

残念ながら、この動作は仕様によるものです。基本的に、/DELAYLOAD を指定すると、リンカーに LoadLibrary 呼び出しと GetProcAddress 呼び出しを挿入するように指示するだけです。その結果、DLL の遅延ロード時の動作は、その DLL を LoadLibrary で動的にロードする場合と同じになります。

MSDNでは、いくつかの結果について説明しています。プラス面として、デフォルトの動作をオーバーライドできます。独自の遅延読み込みヘルパー関数を作成することをお勧めします。

FARPROC WINAPI __delayLoadHelper2(PCImgDelayDescr pidd, FARPROC * ppfnIATEntry)
{
    //...
}

リンカは、遅延ロードされた DLL のエントリ ポイントを解決する必要があるときはいつでも、この関数への呼び出しを挿入します。お使いのバージョンでは、プライベート アセンブリのカスタム検索を実装できます。 MSDN のヘルパー関数に関する追加情報を次に示します。

于 2011-02-16T13:56:22.603 に答える