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.
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