DLL debuggen

[himitsu]

Moin Moin,

ich habe eine DLL und dazu eine EXE (DieTestAnwendung.dpr).

Nun wollte ich zum Debuggen der DLL diese EXE angeben
Menü > Start > Parameter
oder
Projektoptionen > Debugger

Host-Anwendung = $(OUTPUTDIR)\DieTestAnwendung.exe
Arbeitsverzeichnis = $(OUTPUTDIR)
Quellpfad = $(PROJECTDIR)

Aber irgendwie klappt das nicht, wenn ich mit Variablen arbeite (siehe das Edit-Fenster am PostBuildScript)

Es kommt vom Delphi nur

Delphi-Quellcode:

---------------------------
Fehler
---------------------------
Programm 'C:\DasVerzeichnis\%OUTPUTDIR%\DieTestAnwendung.exe' kann nicht gefunden werden.
---------------------------
OK   
---------------------------

Komisch, eigentlich war ich der Meinung, dass die relativen Pfade von der Projektdatei aus gehen, wie es z.B. bei den Ausgabepfaden der DCU und EXE der Fall ist, aber
Host-Anwendung = .\Win32\Debug\DieTestAnwendung.exe

Zitat:

Programm 'C:\DasVerzeichnis\Win32\Debug\Win32\Debug\DieTest Anwendung.exe' kann nicht gefunden werden.

so,

Delphi-Quellcode:

.\Scripting.exe

, sowie

Delphi-Quellcode:

C:\DasVerzeichnis\Win32\Debug\DieTestAnwendung.exe

funktionieren.

Aber absolute Pfade sind ein Nogo
und bei diesem relativen Pfad hab ich immer das Gefühl er wäre falsch, wenn ich ihn sehe. :freak:


Wie gebt ihr sowas dort an?

[jaenicke]

Du brauchst die Hostanwendung gar nicht angeben. Es genügt, wenn beide Projekte in der gleichen Projektgruppe sind und externe Debugsymbole aktiviert sind. Dann kannst du einfach beide Projekte erstellen und die Hostanwendung starten. Du kannst dann in Hostanwendung und DLL gleichermaßen debuggen.

Mit Variablen scheint es jedenfalls nicht zu gehen. Ich habe immer relative Pfade verwendet.

[himitsu]

Ja, alles in einer gemeinsamen Projektgruppe.
Die Projekte liegen im gleichen Verzeichnis und damit auch die Standard-Ausgabepfade an selber Stelle. (EXE und DLL nebeneinander)
Natürlich mit Debuginfos kompiliert.

Wenn ich die EXE im Debugger starte, dann wird die DLL ohne Debuginfos geladen. [edit] komisch, jetzt mit Debuginfos [/edit]

Zitat:

Modul laden: PythonScriptAX.dll. Enthält Debug-Infos. Basisadresse: $5E540000. Prozess Scripting.exe (21048)

Egal ob ich sie vorher in der aktuellen Delphi-Instanz einmal kompiliert hatte oder nicht.

Beim Starten der DLL muß mindestens die Hostanwendung angegeben sein, sonst startet der Debugger ja nicht.

Zitat:

---------------------------
Fehler
---------------------------
Projekt kann nur ausgeführt werden, wenn eine Host-Anwendung festgelegt ist. Verwenden Sie dazu das Dialogfeld "Start|Parameter...".
---------------------------
OK
---------------------------

[edit] vorhin wurde weder von der EXE, noch von der DLL aus jeweils das andere Modul gedebuggt. :gruebel:

Vorhin

[jaenicke]

So wie in deinem Edit sollte es sein. Exe starten, sobald die DLL geladen ist, kann man beide debuggen.

Das klappt leider auch hier nicht immer auf Anhieb. Neustart von Delphi und Erstellen beider Projekte hilft aber meistens.

[himitsu]

Dennoch bleibt, dass ich die relative Pfadangabe dort etwas verwirrend empfinde.
Wie gesagt, sonst ist es relativ zum Projekt, aber hier relativ zum Ausgabeverzeichnis.
[obwohl] Wo ich grade nochmal drüber nachdenke ... bezüglich RemoteDebugging, relativ zum DeployPfad. :stupid:


Nja, mehrfach neu gestartet hatte ich es schon wegen anderer nerviger Macken.
Schon, als ich nur ein Projekt gedebuggt hatte, also noch nicht übergreifend.
* Haltepunkte verschwinden ... kommen 'ne Stunden später zurück
* Haltepunkte verschieben sich, fast jedes Mal, wenn das Debuggen gestartet oder gestoppt wird.
* oft werden sie hier angezeigt, aber sind eigentlich dort
* und wenn die IDE verreckt, ist alles im Arsch, da beim "alles Speichern" nicht der Desktop gespeichert wird.
* * paar Mal ist einfach beim CodeInsight, oder wenn ich in den Property-Editor klicke, die IDE einfach so hängen geblieben
* ...

[himitsu]

boar eh ... mal geht's ne ganze Weile,
dann wieder 'ne Weile garnicht,
dann geht mal absolut garnichts
und einmal sogar falschrum, also nicht das aktive Projekt, aber dafür die fremde Seite (bei Beiden, selbst nach mehreren Wechseln hin und her)

[Andreas13]

Ja, ich weiß: ich bin nur ein blutiger Amateur im Vergleich zu Euch, und auch noch vollkommen fachfremd :( :

Zitat:

Zitat von himitsu (Beitrag 1529012)

... Aber absolute Pfade sind ein Nogo

Aber ich gehe den Weg des NoGo und halte stets den kompletten Pfad der Exe oder DLL im Quellcode fest, kopiere ihn an die richtige Stelle, und es funktioniert einfach, ohne irgendwelche Zicken der IDE.

Ich weiß, es ist überhaupt nicht professionell :oops:, aber es funktioniert bei mir immer... :-D

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1529039)

boar eh ... mal geht's ne ganze Weile,
dann wieder 'ne Weile garnicht,
dann geht mal absolut garnichts
und einmal sogar falschrum, also nicht das aktive Projekt, aber dafür die fremde Seite (bei Beiden, selbst nach mehreren Wechseln hin und her)

Ja, das ist leider so. Bei mir klappt es meistens, aber Fehler gibt es dabei leider immer wieder, egal ob z.B. mit XE6, 10.4 oder 11.3.

Zitat:

Zitat von Andreas13 (Beitrag 1529046)

Aber ich gehe den Weg des NoGo und halte stets den kompletten Pfad der Exe oder DLL im Quellcode fest, kopiere ihn an die richtige Stelle, und es funktioniert einfach, ohne irgendwelche Zicken der IDE.

Ich weiß, es ist überhaupt nicht professionell :oops:, aber es funktioniert bei mir immer... :-D

Das dürfte eher an der Größe der Projekte liegen. Bei kleineren Projekten funktioniert es bei mir auch sehr zuverlässig. Das ist ja auch der Grund, dass Embarcadero das noch nicht behoben hat. Ich bin mir sehr sicher, dass es bei deren Projekten auch besser funktioniert...

[himitsu]

:cry:

@Andreas13
Bei Pfaden, welche zur Laufzeit bestimmt werden,
oder zu Dateien, welche sich nach der Installation nicht verschieben, da sind feste Pfade OK.

Relative Pfade, wenn sie abhängig von z.B. einen veränderlichem Arbeitsverzeichnis abhängen, da sind vollkommen fehleranfällig.

Drum wird da auch immer empfohlen, dass man absolute Pfade benutzen soll, welche man z.B. oft aus einem relativen Pfad zur EXE live generiert.



Die "relativen" Pfade in den Projektoptionen sind fast alle relativ zum Projektverzeichnis (zur DPROJ).
Per se ist das immer gleich, aber man kann z.B. das ganze Projekt verschieben/umbenennen.
* innerhalb der Festplatte
* oder auf mein NAS
* oder ich könnte mein Projekt jemand Anderem geben

Da sind absolute Pfade nicht möglich,
aber relativ (so lange es innerhalb der Projektstruktur liegt) ist dort ideal.

[Andreas13]

Ich sagte doch: ich bin nur ein kleiner Amateur mit kleinen Projekten... :oops: :oops: :oops: