Debuggen einer DLL

[himitsu]

Zitat von Perlsau:

In Dll-Projekten zu debuggen gestaltet sich nicht einfach. Auch ...

Dem kann ich eigentlic nicht zustimmen.

Egal ob DLL und EXE als Host gedebuggt wird,
die EXE, in welcher die DLL "zufällig" geladen wird
oder eine andere DLL, mit einem Host der die eigentliche DLL läd,
es lässt sich alles meistens problemlos Debuggen.

Auch ob die DLL statisch, delayed oder dynamisch geladen wird, macht keinen Unterschied.
Sobald der Debugger die Debuginfos der geladenen Module (EXE, DLL, BPL und selbst wenn die DLL nicht DLL heißt) findet, versteht und läd, ist oftmals alles OK.
Ob er die Debuginfos fand, kann man

Es gibt nur Probleme, wenn der Debugger die Debuginfos nicht findet, womit er dann die Positionen der Zeilen nicht kennt.
Genauso ist es blöd, wenn veraltete Debuginfos geladen werden, da dann die Zeilen mit den Codeadressen nicht mehr übereinstimmen.
Oder beim Compilieren von Projekten/Projektgruppen mit unterschiedlichen Ausgabe- und Suchpfaden.
Oder beim externen Kompilieren (z.B. FinalBuilder) mit anderen Projekteinstellungen (z.B. reingehacktem Eurekalog) oder wenn das Skript nach dem Kompilieren "aufräumt".

Eventuell kann es auch besser sein das Programm erst zu starten und es dannach mit dem Debugger zu verbinden.

Zitat von Sir Rufo:

• Beide Projekte auf Debug

Besch* Einstellungen sollte man natürlich vermeiden.
* Release
* oder "exotische" Compilereinstellungen (nur weil der Punkt "Debug" heist, muß er noch lange nicht auf De)
* auch im Code kann der Compiler gesteuert wurden sein