Frage

Mein Projekt ist ein Plug-In (Windows-DLL), das von einer ausführbaren Hostdatei geladen wird, die nicht unter meiner Kontrolle steht.Meine DLL möchte einige zusätzliche Bibliotheken laden.Ich mache das mit privaten Versammlungen;Es gibt eine tolle Antwort unter Wie kann ein Win32-App-Plugin seine DLL in sein eigenes Verzeichnis laden? wie man das macht.Aber wenn ich hinzufüge /delayload dependentlib.dll in der Verbindungszeile der Haupt-DLL, um zu vermeiden, dass die Assembly geladen wird, bis sie benötigt wird (ich muss dies aus verschiedenen Gründen tun), durchsucht Windows meine privaten Assemblys nicht mehr – es scheint, als würde es das Manifest ignorieren, in das ich kompiliert habe.Stattdessen wird im üblichen Suchpfad nach der verzögert geladenen DLL gesucht.(Ich verwende sysinternals procmon, um dies zu überprüfen.)

Handelt es sich um einen bekannten Fehler oder gibt es eine andere Möglichkeit, das Laden einer Assembly zu verzögern?Ich würde lieber nicht den LoadLibrary + GetProcAddress-Weg gehen, bei dem ich alle Symbole kennen muss, die mir in der abhängigen Bibliothek wichtig sind.

War es hilfreich?

Lösung

Ihr Problem hierbei ist, dass beim ersten Aufruf einer verzögert geladenen Funktion der Standardaktivierungskontext der Anwendung der aktuelle Kontext ist.

Sie müssen lediglich einen Aktivierungskontext erstellen: CreateActCtx Zeigen Sie auf Ihr eigenes Manifest (Instanz+Ressourcen-ID ist meiner Meinung nach möglich).

Schließen Sie dann alle oder zumindest den allerersten Aufruf der DLL mit ein ActivateActCtx (und die entsprechende Deaktivierungsfunktion), um sicherzustellen, dass die richtigen Baugruppen durchsucht werden.

Theoretisch könnten Sie einfach den Code einbetten, um den entsprechenden Kontext im Delayload zu aktivieren Helfer Funktion.

Andere Tipps

Dieses Verhalten ist leider beabsichtigt.Wenn Sie /DELAYLOAD angeben, weisen Sie im Wesentlichen den Linker lediglich an, die LoadLibrary- und GetProcAddress-Aufrufe für Sie einzufügen.Daher ist das Verhalten beim verzögerten Laden einer DLL dasselbe wie beim dynamischen Laden dieser DLL mit LoadLibrary.

MSDN beschreibt einige der Konsequenzen.Positiv ist, dass Sie das Standardverhalten überschreiben können.Ich würde empfehlen, eine eigene Hilfsfunktion für das verzögerte Laden zu schreiben.

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

Der Linker fügt Aufrufe dieser Funktion immer dann ein, wenn er einen Einstiegspunkt in einer verzögert geladenen DLL auflösen muss.Ihre Version könnte eine benutzerdefinierte Suche für Ihre privaten Assemblys implementieren. Hier finden Sie zusätzliche Informationen zur Hilfsfunktion auf MSDN.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top