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.

Zum Debuggen einer DLL packe ich immer beide Projekte in eine Projektgruppe und erzeuge beide von dort. Das klappt in aller Regel problemlos, abgesehen von zu viel Speicherverbrauch damals bei XE6.

Kopierst du nur die DLL oder auch die jeweils aktuellen externen Debugsymbole?

Der Process Monitor könnte zeigen, ob die .rsm Datei an der korrekten Stelle gesucht wird.

Es ist alles in einer Projektgruppe. (abgesehn von den FremdKomponentenPackages)

Normal sind die Debuginfos in der DLL drin (TDS),
aber ich probiere eh grade damit rum die TDS extern zu speichern (dann könnte selektiv debuggen, also z.B. von einigen Basispackages die TDS wieder löschen)

Kopiert wird alles, also quasi "$(outputfile)*.*" ... drum würde ich ungern ins Test-Verzeichnis kompilieren, sondern ins saubere Setup-Verzeichnis.


Die DebugInfos sollten ja in der EXE/DLL drin stecken, daher wird die Datei ja auch enorm größer, wenn man es aktiviert (Debug vs. Releae kompiliert).
Und da die Dateien 100% identisch sind ..........



Die RSM sollte eigentlich unnötig sein, denn normal wird sie ja auch nie benötigt (außer man nutzt den RemoteDebugger),
aber da ich zukünftig die Dateien für den RemoteDebugger direkt erstellen und als ZIP ins Setup packen will, hab ich nun eh aktiviert.


Wie gesagt, im Verzeichnis ist alles identisch, nur das einmal nicht von dort geladen wird, wohin kompiliert wurde.



Ich versuche dann später mal eine kleine Testanwendung (je eine EXE + DLL) zu bauen.

Zitat von himitsu:

Die RSM sollte eigentlich unnötig sein, denn normal wird sie ja auch nie benötigt (außer man nutzt den RemoteDebugger).

Das hätte ich eigentlich auch gedacht, aber die Beschreibung in der Hilfe war da etwas schwammig (lokal behält der Compiler die Debuginfos im Speicher, aber lädt er sie auch für mehrere Projekte?), weshalb ich es bei XE oder so ausprobiert habe. Und siehe da, mit dem Häkchen klappte es plötzlich problemlos.

Das habe ich seither auch bei einigen anderen, die damit Probleme hatten, geraten und es hat oft geholfen, auch bei 32 Bit Anwendungen.

Ich bin mir sicher ich hatte es auch schon probiert, wenn RSM mit daneben liegt, aber kann ja nochmal.

Zumindestens scheint D11 nun bissl besser mit DesignTimePackages zu können ... es entläd beim Kompilieren alle Forms, während XE noch abgeraucht ist, wenn man ein DesignPackage kompiliert, dadurch auch abhängige Packages entladen wurden, welche wiederrum Komponenten enthielten, die grade auf der Form lagen.






Also selbst wenn Ausgabepfad und Debugpfad übereinstimmen:

Ja, im XE mußten wir Packages auch immer erst im Delphi kompilieren, damit ein Debuggen möglich war.
Aber da sind wir davon ausgegangen, dass es an schrottigen Settings und am eurekalog liegt.

* FinalBuilder kompiliert über den ECC32, der den DCC32 startet und da auch noch bissl an den Settings rumpfuscht (so nach dem Motto: ich bin je hier, habe bessere Debuginfos, dann brauchst'e deine nicht mehr, also deaktiiere ich das mal)
* im FinalBuilder für D10/11 lasse ich den Eurekalog im AfterBuild über die ferteige EXE/DLL/BPL laufen und nur noch seine Infos anhängen (seine Resource einfügen, die er aus der MAP generiert)

* im Delphi hängt sich der blöde Eurekalog-Experte ans AfterBuildAll-Ereignis ... also nach dem AfterBuildScript und wenn mehrere Projekte kompiliert werden, dann erst nach ALLEN (echt blöd, wenn man da im AfterBuildScript was machen will, aber der Dreck noch nicht fertig war)
* außerdem fehlt damit das Eurekalog, wenn man MSBUILD nutzt (weil Eurekalog vergessen hat sich dort reinzuhängen)
* im FinalBuilder und D11, also in der DPROJ rufe ich jetzt den EurekaLog immer einheitlich im AfterBuildScript auf und hab die DesignTimePackages vom Eurekalog gesperrt
-> somit sind/sollten die Kompilate vom Delphi und FinalBuilder+MSBUILD nun übereinstimmen

Versucht als Testanwendungen nachzubauen
und da geht es

• erster Commit normal (Package+DLL+EXE)
• aktueller/zweiter Commit mit Umkopieren

Nachfolgendes bezüglich dem lezten Commit (mit Umkopieren)

• _Compile.cmd + _Run.cmd = alles in Ordnung (natürlich nur wenn Delphi 11.x im Standardpfad)
• im Delphi das Projekt TestDLL aktiv -> kompilieren+debuggen -> Haltepunkt in TestPackageUnit.pas stoppt (im richtigen Programm nicht)
  Der Debugger startet bei Package und DLL es auch im Verzeichnis _run
• NUR wenn die EXE aka TestApp aktiv -> da wird vom Debugger der Host in Start->Parameter ignoriert.
  Warum? Es könnte doch auch eine andere EXE sein, welche dann meine EXE aufruft. Und wenn nicht, warum gibt es dann dieses Eingabefeld?
  Außerdem wird das Startverzeichnis ignoriert und startet in _compile anastatt _run