Optionen für den Debugmodus (z.B. an Prozess anhängen etc.)

Question

Hallo zusammen,

ich mache gerade eine Anbindung einer .NET DLL an ein VB6 Programm. Vom VB6 Programm wird die .NET DLL angebunden (COM). Funktioniert bereits gut.

Zum Debuggen der .NET DLL muss ich mich dann an den Prozess des VB6 Programms anhängen. Wenn ich dann Änderungen an der .NET DLL machen will und kompilieren will, scheint das nicht zu gehen, da der VB6 Prozess wohl noch die Resource geblockt hat bzw. auf irgendeine Weise verwendet.

Meine Schritte sind also immer:

1) VB6 Projekt schließen
2) .NET DLL kompilieren
3) VB6 Projekt starten
4) .NET DLL zum Debuggen an den VB6 Prozess anhängen

Kann man das nicht aus VS .NET heraus irgendwie automatisieren? Schön wäre es, wenn beim Kompilieren der .NET der VB6 Prozess beendet würde und dann evtl. das VB6 Projekt wieder neu geöffnet wird und man automatisch an den Prozess (mit einem festen Namen) zum Debuggen angehängt wird.

Geht das irgendwie??

Answer 1

Du kannst die Pre-Build-Einstellung des .NET-Projekts derart anpassen,
dass bspweise ein Batch-File ausgeführt wird (oder eine beliebige Kommandozeile),
der den VB6-Prozess abschiesst bzw die VB-6-IDE schliesst.
Imho hat Visual-Studio 6 sogar ein autmatiserbares Object-Modell, so dass du
den Process nicht stumpf töten musst, sondern sauber herunterfahren kannst...

In den Post-Build-Einstellungen kannst Du dann das Reloaden der IDE, bzw
erneutes Debuggen in einem Skript aufrufen.

Pre- und Post-Buitd-Einstellungen findest in den Eigenschaften des .NET-Projekts
unter "Built-Events" (schätzungsweise "Built-Ereignisse" in de-de-VS-Versionen).

Ist aber sicherlich viel Frikkel-Arbeit mit vielerlei Seiten-Aspekten.
Beide IDEs parallel geöffnet zu halten und eben eins nach dem anderen unter
manueller Kontrolle auszuführen, ist wohl "gesünder".

Christoph

Answer 2

Beide IDEs offen zu halten, wäre auch aus meiner Sicht gesünder, aber leider nimmt die VB6 IDE wohl die COM DLL, die im VS .NET entwickelt ist "gefangen", so dass ein erneutes Kompilieren nach Änderungen gar nicht klappt, ohne dass die VB6 IDE wieder geschlossen wird.

Geht das Anhängen an einen bestimmten Prozess in den Post-Build-Ereignissen dann auch irgendwie? Es muss also im Post-Build immer ein bestimmtes Projekt aufgemacht werden, was wohl recht simpel zu realisieren sein wird. Danach muss aber das Projekt auch in der VB6 IDE gestartet werden und VS muss sich dann dran hängen.

 

Wo meinst Du, finde ich das VS 6 "Objektmodell" zum sauberen Herunterfahren? Müsste das dann Deiner Meinung nach ein Parameter in der VB6.exe z.B. sein, der dann im Batch ausgeführt wird?

Answer 3

Hallo S.,

Ich wollte Dir gerade late binding als Lösungweg vorschlagen, habe aber festgestellt dass das nur in bestimmten Szenarien Wirkung zeigt. Schade.

Frag doch mal bitte auch im VB-Forum nach, vielleicht gibt es dort noch mehr Hinweise für Dich. 

Gruß
Marcel

Answer 4

Ich habe ein Batch, um VB6 mit dem richtigen Proekt zu kompilieren. Habe versucht das mit

CALL "C:\Documents and Settings\...\MyBatch.bat"

im Post-Build einzubinden. Es kommt aber immer, dass das mit Fehler 1 beendet wurde. Das Batch alleine für sich gestartet, macht aber schon, was es soll.

 

Was mache ich hier falsch, dass das nicht richtig gemacht wird? Kann das auch an der Build-Reihenfolge in meiner Solution liegen? In der Solution werden mehrere Projekte eingebunden und gebildet. Das Projekt, das als Start-Projekt festgelegt ist, hat dann das Post-Build wie oben.

Answer 5

cmd /c "C:\Documents and Settings\...\MyBatch.bat"

bzw auch

cmd /c start /wait "DummyTitle" "C:\Documents and Settings\...\MyBatch.bat"

wäre wohl was Du suchst.
CALL wird nur innerhalb einer Batch verstanden aber nicht als cmdline in Visuals Studio bzw in Windows generell.

Christoph

Answer 6

Das verstehe ich nicht so ganz.
Das Anhängen an einen Prozess kann man zwar einzeln pro Debug-Session starten,
indem man unter "Debug" diesen Schritt selektiert und dann einen laufenden Prozess hookt....
-  oder man kann es als Standard-Starteinstellung in den Projekteinstellungen konfigurieren,
dann geht es immer, sobald Du F5 drückst.
Ich denke Variante 2 ist was Du suchst.

Das geht in den Projekteigenschaften nicht unter Build-Ereignissen, sondern ihmo unter
"Debuggen" (habe gerade lokal kein VS, daher kann ich Dir nicht sagen, wo genau).
Dazu wählst Du bei DLL-Projekten den festen Pfad zu einem Executable, also deiner VB-6-exe
in "Auszuführende Datei".

Wenn Du das so konfiguriert hast, startet bei F5 deine .NET-DLL und
parallel dazu der VB-COM-Client. So dass Du in .NET gleich Debuggen kannst.

Christoph

 

Answer 7

Hallo SP.,

"call" ist schon eine gute Wahl.

[Seite "Buildereignisse", Projekt-Designer (C#)]
http://msdn.microsoft.com/de-de/library/e2s2128d.aspx
Zitat: "Fügen Sie vor allen Postbuildbefehlen, die BAT-Dateien ausführen, eine call-Anweisung hinzu ..."

Dein Fehler kann durch ein falsches Verzeichnis/Pfad enstehen.

Nutze besser und sauberer folgendes:

1. Ziehe die bat (Build) Datei in Dein Projekt (DragDrop).
2. Ändere die Zeile für den PostBuild-Stepfolgendermaßen:
    
       call "$(ProjectDir)test.bat"

(ich persönlich nehme gern VBS, aber kein Problem, das geht natürlich mit BAT).
Wenn jetzt Dein Projekt verschoben wird, stimmt die Pf´fadangabe immernoch.

---

ciao Frank

Answer 8

Hallo Christoph,

     > cmd /c start  .. wäre wohl was Du suchst.

das wäre doppelt gemoppelt.
Visual Studio startet intern schon eine Shell, in der Du dann quasi noch ein Shell starten würdest.
Das ist aber nicht nötig, da es extra dafür den Befehl "call" für die Shell gibt.

---

ciao Frank

Answer 9

Das mit der F5-Variante wäre genau das, was ich haben möchte. Leider klappt das nicht und mir wird eine Meldung ausgegeben, dass das bei Projekten vom Typ Klassenbibliothek nicht funktioniert. Stimmt natürlich. Ich hab dann auch mal das Projekt als Windows-Anwendung kompilieren lassen, aber auch das funktioniert nicht.

Die ganze Solution besteht aus mehreren Teilprojekten, die eingebunden werden. Dann hab ich noch am Ende ein leeres Projekt mit angehängt, das dann die Start-Einstellungen für VB6 haben sollte, so wie Christoph Basedau es vorgeschlagen hat. Leider tut das auch nicht. Die Einzelprojekte sind alle vom Typ Klassenbibliothek und für COM registriert.

Geht das dann gar nicht??

Answer 10

Hallo SPDeveloperXP

Also folgende Anforderungen müssen umgesetzt sein:

• .NET-DLL-Projekt hat unter
  Projekteigenschaften / Debug / Starte externes Programm
  den Pfad der VB-exe eingetragen.
• .NET-DLL ist Startprojekt der VS-Solution ("fett" markiert im Sol.-Explorer)
• damit COM-Interaktion funktioniert muss die .NET-DLL
  
  • COM-visible sein,
  • mit eine "strong name" signiert sein ("sn.exe").
  • Sie muss mit reagsm registriert sein und eine TLB exportieren
    Dabei auf die richtige DLL-Version achten (Stichwort Debug/Release)
  • Sie muss in den GAC kopiert worden sein, mittels GACUTIL.
• Das VB-Projekt muss die aktuelle Version der TLB referenzieren (also selbe GUIDs)
  nicht nur die selbe ProgID.
  Dadurch sollte beim Aufruf des .NET-COM-Servers der Debugger in den .NET-Quellcode
  einsteigen, z.B. Breakpoints wirksam werden.
• Damit das Kompilieren der .NET-DLL funktioniert, muss die VB-IDE im Pre-Build
  event per cmdline geschlossen werden (egal ob via VB-Skript, Batch, etc)
  bzw eigentlich musss nur das File-Handle auf die .NET-DLL geschlossen werden,
  aber das läuft auf das selbe hinaus.
• Optional kann die VB-6-IDE im Post-Build wieder geladen werden.
  
  
  
  Wenn diese Anforderungen umgestzt sind, MUSS das Starten des Debuggens ("F5")
  bewirken, dass das .NET-Projekt nötigenfalls neu kompiliert wird, das die VB-6-Anwendungen
  gestartet wird (aber nicht über die VB-6-IDE) und auch deren Quellcode gedebuggt werden
  kann.
  Wenn das so nicht funktioniert, dann wären konkrete Angaben zu Fehlern oder anderen
  Beobachtungen nützlich.
  Dass F5 ohne ein externes Startprojekt bei einer DLL nichts bringt ist klar,
  ein zusätzliches leeres ausführbares .NET-Dummy-Projekt löst es aber nicht ;-)
  
  
  Gruß
  Christoph

Answer 11

Super! So funktioniert das jetzt, wie gewünscht. Ich könnte mir vorstellen, dass das COM-Visible mein Problem war, denn das mit "Externes Programm starten" in den Projekt-Eigenschaften hatte ich auch schon versucht, aber leider ohne Erfolg.