PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Visual Studio automatisch an Prozess "attachen"


Elemental
2013-09-04, 09:13:34
Hallo zusammen,
ich habe eine Solution in Visual Studio, die zwei .exe Projekte enthält.
Das eine ist die GUI und das andere ein "Worker Prozess".
Die GUI spawned mehrere "Worker Prozesse", die über Sockets mit der GUI kommunizieren.
Ich würde nun gerne die "Worker Prozesse" debuggen. Das geht,wenn ich manuell VS an die Prozesse attache. Aber kann ich auch irgendwie automatisch den Prozess an mein offenes VS attachen.
Ich hab nur Befehle gefunden, die ein neues VS öffnen und den Prozess daran attachen.

Besten Dank im voraus
Elemental

Gnafoo
2013-09-04, 12:07:54
Es gibt in Windows wohl einen Mechanismus dafür, den Visual Studio aber leider nicht unterstützt (siehe hier (http://www.wintellect.com/blogs/jrobbins/can-the-vs-debugger-automatically-attach-to-any-child-spawned-by-a-process-being-debugged)). Mit WinDBG ist es wohl möglich (allerdings habe ich das nie getestet, weil ich gerne in der IDE debuggen möchte).

Ich suche auch noch verzweifelt nach einer Möglichkeit, mit der ich es zumindest irgendwie hintricksen kann, weil ich an der Arbeit das selbe Problem habe.

Geht es denn um C++ oder C#/.NET und co.?

Elemental
2013-09-04, 12:38:12
Bei mir sind es C# Projekte.

Gnafoo
2013-09-05, 19:34:03
Ist zwar ein ziemliches gehacke, aber das hier kann man von den Client/Worker-Prozessen aus machen, um diese zu attachen:
http://stackoverflow.com/questions/3268483/getting-running-visual-studio-2010-instances-and-programmatically-attaching-to-a/3268736#3268736

Nur die PID vom Visual Studio braucht man noch von irgendwoher.

del_4901
2013-09-05, 20:23:02
Du kannst auch einfach eine Endlossschleife einbauen und mit dem Debugger dann druebersteppen.

Elemental
2013-09-10, 20:44:01
Du kannst auch einfach eine Endlossschleife einbauen und mit dem Debugger dann druebersteppen.

Du meinst manuell attachen? Das mache ich bisher, aber ist sehr unpraktisch.

Ich habe in der GUI eine Liste mit "Aufträgen" die abgearbeitet werden müssen. Im konkreten Fall 1000 Aufträge und für jeden Auftrag wird ein Prozess gespawned. Die Anzahl gleichzeitig laufender Prozesse ist einstellbar, max. aber die Anzahl an CPU-Kernen.

Bei mir laufen also immer 8 Worker-Prozesse und bearbeiten die Aufträge. Wenn ein Auftrag abgeschlossen ist, beendet sich der Prozess und die GUI startet einen neuen Worker-Prozess für den nächsten Auftrag.


Bisher debugge ich, indem ich die Anzahl gleichzeitiger Worker-Prozesse auf 1 bregrenze und mich manuell attache. Bestimmte Probleme kann ich so aber nich nachstellen, da sie nur auftreten, wenn das System ausgelastet ist...

Coda
2013-09-10, 23:31:59
http://msdn.microsoft.com/en-us/library/a329t4ed(v=vs.100).aspx

Gnafoo
2013-09-11, 04:07:02
Bisher debugge ich, indem ich die Anzahl gleichzeitiger Worker-Prozesse auf 1 bregrenze und mich manuell attache. Bestimmte Probleme kann ich so aber nich nachstellen, da sie nur auftreten, wenn das System ausgelastet ist...

Naja du kannst zumindest mit Shift mehrere Prozesse markieren und dich dann an alle ausgewählten attachen. Ist natürlich trotzdem noch umständlich.

Elemental
2013-09-11, 07:57:30
http://msdn.microsoft.com/en-us/library/a329t4ed(v=vs.100).aspx

Das startet ja auch nur einen neuen Debugger, und hängt den neuen Prozess nicht automatisch an das laufende Visual Studio.

Sowas geht auch einfacher in .NET, wenn ich am Anfang meines Worker-Prozesses ein
System.Diagnostics.Debugger.Launch()
einbaue.


soweit ich das bisher überblicke, ist die einzige Lösung wirklich das COM Automation Interface von Visual Studio, so wie Gnafoo es schon gepostet hat. Aber schön ist das nicht...