Hallo allerseits!
Ich habe hier ein Projekt, das unter Windows implizit eine DLL lädt. Ich compiliere unter VC++ Express 2008, mit einem vcproj das aus einen Qt PRO file erzeugt wird.
Es gibt von dieser DLL aber sowohl eine Debug- auch als eine Release-Variante, jeweils in unterschiedlichen Ordnern.
Natürlich würde ich in der Release-Variante der Applikation auch gerne die Release-Variante der DLL laden (und analog für die Debug-Varianten). Das ist leider nicht ganz einfach. Genauer gesagt, habe ich keine Idee, wie ich das machen könnte. Man könnte das eventuell irgendwie über die PATH Umgebungsvariable lösen. Gibt es vielleicht eine Möglichkeit das irgendwie im PRO file Target-Abhängig zu verankern?
Bin für jede Idee dankbar.
DLL je nach Debug/Release laden
-
Silicomancer
- Beiträge: 17
- Registriert: 3. Dezember 2009 14:04
nein, das laden einer Dll wird dynamisch, also ueber variablen gesteuert, nich uebern praeprozessor. Du koenntest naturlich ueber praeprozessorsymbole variablen switchen. (Geht nur wenn volle kontrolle ueber das laden hasst, also nicht die importlib variante).Gibt es vielleicht eine Möglichkeit das irgendwie im PRO file Target-Abhängig zu verankern?
wie ziehst du deine Dll an ?
ueber eine Importlib ? oder richtig dynamisch ueber loadlibrary ?
Wie sehen deine Schnittstellen aus ? geht da QT Zeugs drueber? Auch Zeugs was auf ressourcen zugreift ?Natürlich würde ich in der Release-Variante der Applikation auch gerne die Release-Variante der DLL laden
Wenn ja, dann funktioniert sogar nur die release exe mit der release dll, und dementsprechend auch das mit debug ... beim vermischen wuerde dir das knallen.
Wo liegt deine DLL normal ?
Ciao ...
-
Silicomancer
- Beiträge: 17
- Registriert: 3. Dezember 2009 14:04
Die DLL wird über das Linken eines .lib Stubs eingebunden. Das ist ja grade das Problem. Mit LoadLibrary wäre das nicht ganz so schwer :-/
Die Namen der DLLs kann ich leider nicht ohne weiteres verändern. Ich kann die DLLs zwar selber bauen, aber es geht um ein für mich eigentlich unveränderliches third-party DLL-Software-Paket (übrigens ohne Qt), das nach dem Compilieren nunmal zwei DLLs (einmal debug einmal release) auswirft - mit identischen Namen aber dafür in unterschiedlichen Ordnern.
Ich möchte das darum möglichst irgendwie über meine Tool-Chain abwickeln. Würde ich die DLL-Target-Namen im DLL-Projekt ändern, käme das DLL-Software-Paket möglicherweise nicht damit zurecht, da es seine selbstproduzierten DLLs auch für eigene Zwecke verwendet (und nicht nur mir zur Verfügung stellt).
Ich könnte die Dateien natürlich nach dem bauen über meine eigene Tool-Chain kopieren und umbenennen: Also z.B. xxx.dll und xxx.lib der debug-Variante nach xxxd.lib/xxxd.dll - aber leider reicht das meines Wissens nach nicht: Wenn ich nur die Dateinamen ändere, verweist die xxxd.lib immernoch auf die xxx.dll.
Jegliche Maßnahmen in meiner Applikation scheiden auch aus, da die DLL schon geladen wird, bevor überhaupt main() aufgerufen wird.
Hat jemand anderen Ideen?
Die Namen der DLLs kann ich leider nicht ohne weiteres verändern. Ich kann die DLLs zwar selber bauen, aber es geht um ein für mich eigentlich unveränderliches third-party DLL-Software-Paket (übrigens ohne Qt), das nach dem Compilieren nunmal zwei DLLs (einmal debug einmal release) auswirft - mit identischen Namen aber dafür in unterschiedlichen Ordnern.
Ich möchte das darum möglichst irgendwie über meine Tool-Chain abwickeln. Würde ich die DLL-Target-Namen im DLL-Projekt ändern, käme das DLL-Software-Paket möglicherweise nicht damit zurecht, da es seine selbstproduzierten DLLs auch für eigene Zwecke verwendet (und nicht nur mir zur Verfügung stellt).
Ich könnte die Dateien natürlich nach dem bauen über meine eigene Tool-Chain kopieren und umbenennen: Also z.B. xxx.dll und xxx.lib der debug-Variante nach xxxd.lib/xxxd.dll - aber leider reicht das meines Wissens nach nicht: Wenn ich nur die Dateinamen ändere, verweist die xxxd.lib immernoch auf die xxx.dll.
Jegliche Maßnahmen in meiner Applikation scheiden auch aus, da die DLL schon geladen wird, bevor überhaupt main() aufgerufen wird.
Hat jemand anderen Ideen?
Deswegen ja die Frage, wo die "Dinger" liegen.Die Namen der DLLs kann ich leider nicht ohne weiteres verändern.
da du importlibs hasst, bist du auf einen Loadlibrary aufruf mit nur dem DLL-Namen ohne Pfad bei der Statischen initialisierung (also vor der main()) festgenagelt.
Daran kannst du nix aendern ! (oder du muesstest die Projekteinstellungen Aendern des fremden dll projects, was oftmals nicht in frage kommt)
der einzige Anker ist, wie Windows DLL's sucht, wenn loadlibrary ohne PathInfos aufgerufen wird.
Standardmaessig sucht windows da:
- gleiches verzeichnis wie die exe
- die Pfade aus der PATH Ungebung deines Prozesses
- Windows Systemverzeichnisse (system / system32 .... )
In der Reihenfolge !
Nur am Rande:
Das kann geaendert werden ueber die regestry ... Im Normal-Fall isses das aber nicht. Aber prinzipiell könnt man nen Safe Windows bauen, was nur dlls aus "sicheren" verzeichnissen anzieht. Aber rat mal, was fuer SW darauf laufen wuerd
Du erzeugst doch aber Die Exe ? warum legst du ueber nen Install script oder aehliches nicht einfach die passende dll daneben(ins selbe verzeichnis) ?
Dann kannst du von deiner SW ne Debug und Release variante gleichzeitig aufm rechner haben, und beide ziehen unterschiedliche (aber passende) versionen der Fremd-Dll an !
Und noch ne Frage .,.. warum willst du die Debug version deines Progs gegen die Debug version der Fremd-Dll laufen lassen ? Hasst du Probleme das debug und release nicht zusammenarbeiten ? oder willst du in den Code der Dll debuggen ?
Ciao ...
-
Silicomancer
- Beiträge: 17
- Registriert: 3. Dezember 2009 14:04
Gute Idee. Aber wie mache ich das? Ich wüßte nicht mal, wie ich das ausschließlich mit VC++ löse - aber noch weniger Ahnung habe ich, wie ich das über qmake und ein .pro file machen kann (wie gesagt ich erzeuge mein vcproj über qmake/.pro, also müßte das im .pro verankert sein). Ich müßte jedes mal wenn mein exe gebaut wird, die richtig DLL kopieren, das wäre eine gute Lösung.RHBaum hat geschrieben: Du erzeugst doch aber Die Exe ? warum legst du ueber nen Install script oder aehliches nicht einfach die passende dll daneben(ins selbe verzeichnis) ?
Dann kannst du von deiner SW ne Debug und Release variante gleichzeitig aufm rechner haben, und beide ziehen unterschiedliche (aber passende) versionen der Fremd-Dll an !
Ich will die DLL debuggen.RHBaum hat geschrieben: Und noch ne Frage .,.. warum willst du die Debug version deines Progs gegen die Debug version der Fremd-Dll laufen lassen ? Hasst du Probleme das debug und release nicht zusammenarbeiten ? oder willst du in den Code der Dll debuggen ?
von der Dll, kannst du das .pro file anpassen oder Nich ?
Das .vcproj oder die .pdb musst ja eh haben, sonst kannst ned debuggen ....
Ohne Die Projecte anzupassen geht das erstmal unautomatisiert bissi umstaendlich und wenn deine exe userinput hat und nicht gleich durch die zu debuggende funktionalitaet durchrauscht, folgendermassen:
Du baust deine exe im debugmodus normal wie immer.
er erzeugt die die exe, alles wunderbar.
due oeffnest das DLL project und erstellst die dll als debug build.
er erstellt die die dll, alles wunderbar.
du kopierst die erstellte dll nun einfach neben die exe.
du fuehrst die exe aus (direkt, ohne ueber das VS zu gehen)
du wechselst zurueck ins VS mit dem dll project
dort unter debuggen, an Prozess anhaengen -> die exe deines grad gestarteten Projectes auswaehlen ...
Breakpoints im dll code setzten an der stelle wo debuggen willst ...
zur exe wechseln und das tun, was den zu debuggenden code in der dll anspringen sollt.
voiala der focus springt zurueck zum VS Studio zur dll an den entsprechenden Breakpoint.
Generell
DU kannst im qmake die zielpfade angeben, wo der dir dein zeug hinkompiliert. das wird dann auch in die vcproj uebernommen. wenn das bei der dll und der exe anpassen kannst, kann er gleich in die richtigen zielverzeichnisse reinbauen.
Dann kannst im dll project gleich die exe ohne kopieren ausfuehren und direkt debuggen, ohne an den prozess anhaengen zu muessen.
Das .vcproj oder die .pdb musst ja eh haben, sonst kannst ned debuggen ....
Ohne Die Projecte anzupassen geht das erstmal unautomatisiert bissi umstaendlich und wenn deine exe userinput hat und nicht gleich durch die zu debuggende funktionalitaet durchrauscht, folgendermassen:
Du baust deine exe im debugmodus normal wie immer.
er erzeugt die die exe, alles wunderbar.
due oeffnest das DLL project und erstellst die dll als debug build.
er erstellt die die dll, alles wunderbar.
du kopierst die erstellte dll nun einfach neben die exe.
du fuehrst die exe aus (direkt, ohne ueber das VS zu gehen)
du wechselst zurueck ins VS mit dem dll project
dort unter debuggen, an Prozess anhaengen -> die exe deines grad gestarteten Projectes auswaehlen ...
Breakpoints im dll code setzten an der stelle wo debuggen willst ...
zur exe wechseln und das tun, was den zu debuggenden code in der dll anspringen sollt.
voiala der focus springt zurueck zum VS Studio zur dll an den entsprechenden Breakpoint.
Generell
DU kannst im qmake die zielpfade angeben, wo der dir dein zeug hinkompiliert. das wird dann auch in die vcproj uebernommen. wenn das bei der dll und der exe anpassen kannst, kann er gleich in die richtigen zielverzeichnisse reinbauen.
Dann kannst im dll project gleich die exe ohne kopieren ausfuehren und direkt debuggen, ohne an den prozess anhaengen zu muessen.
Du kannst im pro file je nach Konfiguration unterscheiden:
CONFIG(debug) {
DEFINES -= QT_NO_DEBUG_OUTPUT
LIBS += deineDebugLib.lib
}
else {
DEFINES += QT_NO_DEBUG_OUTPUT
LIBS += deineReleaseLib.lib
}
Dann je nach Bedarf
qmake CONFIG+= debug CONFIG-=release (-r -tp vc)
oder eben
qmake CONFIG-= debug CONFIG+=release (-r -tp vc)
ausführen.
So machen wir das jedenfalls....
Viel Erfolg
CONFIG(debug) {
DEFINES -= QT_NO_DEBUG_OUTPUT
LIBS += deineDebugLib.lib
}
else {
DEFINES += QT_NO_DEBUG_OUTPUT
LIBS += deineReleaseLib.lib
}
Dann je nach Bedarf
qmake CONFIG+= debug CONFIG-=release (-r -tp vc)
oder eben
qmake CONFIG-= debug CONFIG+=release (-r -tp vc)
ausführen.
So machen wir das jedenfalls....
Viel Erfolg