Kompiliert wird wird eine
DLL ins Verzeichnis A (BPLOutput)
im AfterBuildScript wird Diese nach Verzeichnis B kopiert und vorher noch der ECC (Eurekalog) drübergejagt.
Als Host ist die EXE im Testverzeichnis B angegeben.
Geladen wird dann auch die
DLL aus Verzeichnis B.
Dateien in A und B sind 100% identisch.
Aber dennoch meint der Debugger
Zitat von
Ereignisse-Tab:
Modul laden: xxxxx.dll. Ohne Debug-Infos. Basisadresse: $01F60000. Prozess yyyyy.exe (1544)
Gebe ich im BPLOutput das Verzeichnis B an und kopiere nach A (und lade dann ebenfalls B),
dann funktioniert es plötzlich.
Zitat von
Ereignisse-Tab:
Modul laden: xxxxx.dll. Enthält Debug-Infos. Basisadresse: $19360000. Prozess yyyyy.exe (6224)
Es ist auch egal ob mit internen oder externen TDS, bzw. auch ob zusätzlich RSM vorhanden.
Es ist jeweils genau die selbe
DLL, einmal umkopiert oder direkt geladen.
Ich will damit aufhören, dass FinalBuilder und Delphi/Debugger unterschiedlich arbeiten.
- FB ins A kompilieren und nach B kopieren, aber Delphi ins B kompilieren und nach A kopieren,
vor allem da FinalBuilder mit MSBuild genau das Selbe machen soll, wie die Delphi-IDE. (früher war FB mit DCC32 und einer doppelten ProjektConfig)
- Für ein sauberes Verzeichnis ist es besser in das Verzeichnis zu kompileren, welches dann auch vom Setup-Generator verwendet wird
und eben nicht ins Testverzeichnis, wo eventuell "komisches" rauskopiert würde.
Kurz nach dem Kompilieren sind die blauen Punkte noch da,
dann beim Start der EXE sind sie weg (so weit OK)
und sobald die
DLL geladen wird, sollten sie seigentlich zurückkommen.
Jetzt auch noch in jedes der fast 100 Projekte (Packages/DLLs/usw.) eine weitere abgeleitete Config, welche (hoffentlich) nur den anderen Ausgabepfad nutzt, für den Build aus dem FinalBuilder, wäre nicht unbedingt schön,
vor allem da ich keinen Grund sehe, warum Delphi sich weigert die Debug-Infos zu laden.