Debuggen in Visual Studio .NET

Veröffentlicht: 07. Mrz 2002 | Aktualisiert: 16. Jun 2004

Zusammenfassung: Dieser Artikel behandelt einige der neuen und verbesserten Funktionen des Microsoft® Visual-Studio®-.NET-Debuggers, wie beispielsweise sprachübergreifendes Debuggen, Debuggen mehrerer Prozesse auf verschiedenen Computern sowie die Generierung von Minidumps für C++-Anwendungen.

Auf dieser Seite

 Einführung
 Sprachübergreifendes Debuggen
 Debuggen mehrerer Prozesse auf verschiedenen Computern
 Debuggen von ASP.NET
 Debuggen von Visual C++-Anwendungen
 TSQL-Debuggen
 Automatisierungsmodell
 Installieren von Komponenten zum Remotedebuggen
 Schlussfolgerung

Einführung


Visual Studio .NET ist eine leistungsstarke Entwicklungsumgebung, die die Entwicklung einer Vielzahl von Anwendungen unterstützt, angefangen bei ATL Server und ASP.NET-Webanwendungen bis hin zu Desktopanwendungen in Visual Basic® .NET. Der effiziente Debugger von Visual Studio .NET ermöglicht das Debuggen dieser Szenarien.

Visual Studio .NET verfügt über drei hervorragende Voraussetzungen zum Debuggen:

  • Eine einzelne Benutzeroberfläche für alle Sprachen

    Wenn Sie als Entwickler in mehreren Sprachen programmieren, brauchen Sie Ihre Umgebung oder Tastenbelegung nicht zu ändern, wenn Sie die Sprache wechseln. Sämtliche Debugbefehle, die Platzierung von Debugfenstern und auch (zu einem Großteil) Ihre Debugfeatures bleiben in den verschiedenen Sprachen unverändert. Außerdem unterstützt die einzelne Benutzeroberfläche ein gewohntes, schnelleres und einfacheres Arbeiten in der Entwicklungsumgebung.

  • Gleichzeitiges Debuggen mehrerer Prozesse auf verschiedenen Computern

    Dies ist speziell beim Debuggen von Client/Server-Anwendungen hilfreich, bei denen der Client auf einem Computer installiert ist und mit einem Webserver auf einem anderen Computer kommuniziert. Mit Visual Studio .NET können Sie gleichzeitig und computerübergreifend debuggen und die Ausführung Ihrer Anwendung analysieren.

  • Leistungsstarkes übergreifendes Debuggen zwischen einzelnen Sprachen

    Wenn Sie mit Visual Basic .NET programmieren und Komponenten verwenden, die in C# geschrieben sind, haben Sie die Möglichkeit, während des Debuggens problemlos zwischen den beiden Sprachen zu wechseln. Generell können Sie zwischen allen Sprachen wechseln, die auf die Common Language Runtime (gemeinsame Sprachlaufzeit) aufsetzen. Darüber hinaus ermöglicht Ihnen Visual Studio .NET den Wechsel zwischen .NET-Framework-Anwendungen und Visual-C++®-Code. Dies ist besonders bei der Interaktion mit bestehenden COM-Komponenten sinnvoll. Außerdem können Sie in gespeicherten Prozeduren debuggen, die Ihr Code in Visual Studio .NET aufruft.

Sprachübergreifendes Debuggen


Ein leistungsstarkes Feature von Visual Studio .NET ist das übergreifende Debuggen in Sprachen, die auf der Common Language Runtime aufsetzen, und in Ausführungsumgebungen. Wenn Sie z.B. eine Visual-Basic-.NET-Komponente schreiben, die von einer C#-Komponente aufgerufen wird, die ihrerseits durch COBOL-Code (der auf der Laufzeit aufsetzt) aufgerufen wird, haben Sie die Möglichkeit, während des Debuggens problemlos zwischen den Sprachen zu wechseln. Darüber hinaus zeigt ein einzelner Aufrufstapel die unterschiedlichen Funktionen an, die in den durchlaufenen Sprachen aufgerufen wurden.

Zudem können Sie auch zwischen C++-Code und jeder .NET-Framework-Sprache wechseln. Code, der für .NET-basierte Anwendungen geschrieben wurde, kann mittels Platform Invoke, COM-Interoperabilität oder über verwaltete C++-Erweiterungen mit C++-Code arbeiten. Sie können ohne Übergang zwischen den Sprachen wechseln und debuggen. Auch hier zeigt der Debugger wieder einen Aufrufstapel mit sämtlichen Komponenten an. Zum übergreifenden Debuggen zwischen dem CLR-Code (Common Language Runtime) und dem systemeigenen C++-Code müssen Sie eine Option in den Einstellungen Ihres Startprojekts ändern. Suchen Sie im Projektmappen-Explorer Ihr Startprojekt (der Name ist fett markiert). Dieses Projekt wird gestartet, wenn Sie F5 drücken. Zum Debuggen von Laufzeit- und systemeigenem Code muss das Startprojekt so konfiguriert werden, dass es beide Arten des Debuggens unterstützt. Öffnen Sie dazu die Projekteigenschaften, und wählen Sie unter Konfigurationseigenschaften den Ordner Debuggen aus.

  • Visual Basic .NET- oder Visual C#T-Projekte:

    Stellen Sie sicher, dass die Option Nicht verwaltetes Debuggen aktivieren ausgewählt ist. In Visual Basic wird diese Option über ein Kontrollkästchen aktiviert, in Visual C# über eine Option in der Dropdownliste.

  • Visual C++-Projekte:

    Ändern Sie den Debuggertyp in Gemischt.

    Anmerkung Eine weitere Option, Automatisch, muss näher erläutert werden. Sie untersucht Ihre ausführbare Datei und bestimmt, ob die Anwendung sowohl den systemeigenen als auch den verwalteten Code aufruft. Basierend auf den Analyseergebnissen werden zum Debuggen die entsprechenden Debugger verwendet. Der Nachteil bei dieser Methode ist, dass nicht erkannt wird, wenn ein Projekt mit verwalteten C++-Erweiterungen geschrieben wurde und dynamisch systemeigenen Code geladen hat, so dass Sie den systemeigenen Code nicht debuggen können. Durch die Einstellung Gemischt hat der Entwickler die Möglichkeit, die Debugoptionen direkt zu steuern.

Alternativ können Sie auch mit den C++- und Laufzeitdebuggern eine Verbindung zu einem laufenden Prozess herstellen. Wenn Sie mit dem Dialogfeld Prozesse eine Verbindung zu einem Prozess herstellen, wählen Sie die Debuggeroptionen Common Language Runtime und Systemeigen aus. Dadurch haben Sie die Möglichkeit, zwischen systemeigenem Code und Laufzeitcode zu wechseln.

Debuggen mehrerer Prozesse auf verschiedenen Computern


Mit dem Visual-Studio-.NET-Debugger können Sie nicht nur mehrere Prozesse gleichzeitig, sondern auch Prozesse auf mehreren Computern gleichzeitig debuggen. Mit Visual Studio .NET starten Sie mehrere Prozesse und debuggen diese gleichzeitig. Fügen Sie dazu Ihrer Projektmappe mehrere Projekte hinzu. Legen Sie in den Eigenschaften der Projektmappe die Option Mehrere Startprojekte fest, damit alle Projekte beim Drücken von F5 gestartet werden. Dadurch werden alle Prozesse im Debugger gestartet, und Sie können sie alle gleichzeitig debuggen.

Alternativ können Sie mit dem Dialogfeld Prozesse speziell eine Verbindung zu Prozessen auf unterschiedlichen Computern herstellen und diese gleichzeitig debuggen. Beachten Sie, dass Debuggingkomponenten auf dem Remotecomputer installiert sein und Sie über die entsprechenden Berechtigungen zum Debuggen der Prozesse verfügen müssen.

Sie können auf zwei Arten jederzeit feststellen, welche Prozesse Sie momentan debuggen:

  • Mit dem Dialogfeld Prozesse

    Klicken Sie im Menü Debuggen auf Prozesse, um das Dialogfeld Prozesse zu öffnen. Im unteren Fensterbereich werden die Prozesse angezeigt, die Sie derzeit debuggen.

    Abbildung 1. Dialogfeld "Prozesse"

    processdialog

  • Mit der Symbolleiste Debugspeicherort

    Diese neue Symbolleiste in Visual Studio .NET ermöglicht Ihnen die schnelle Anzeige der Programme, an die Sie angefügt sind, der Threads in jedem Programm sowie des Stapelrahmens jedes Threads. Sie kann zudem als schnelle Alternative zum Öffnen des Fensters mit den Aufrufstapeln und Threads verwendet werden.

    Abbildung 2. Symbolleiste "Debugspeicherort"

    debuglcntlbar

Debuggen von ASP.NET


ASP.NET ist eine vereinheitlichte Plattform zur Webentwicklung mit einem neuen Programmiermodell und Framework zur Entwicklung stabiler, sicherer und skalierbarer Anwendungen. Mit Visual Studio .NET lassen sich ASP.NET-Anwendungen einfach und problemlos entwickeln. Die Umgebung ist so konzipiert, dass sich die Webentwicklung wie die Entwicklung formularbasierter Clientanwendungen gestaltet. Die Taste F5 funktioniert also in einer Webanwendung genau wie in einer formularbasierten Anwendung.

Debuggen von Webdiensten

Webanwendungen und Webdienste können mit Visual Studio .NET problemlos gedebuggt werden. Standardmäßig wird durch Drücken von F5 in einem Webdienstprojekt eine einfache Testseite angezeigt, über die Sie die Webdienste aufrufen können, die Sie entwickelt haben. Das Debuggen dieses Codes ist einfach. Setzen Sie einfach Ihre Haltepunkte in Ihrem Webdienstcode, und rufen Sie die Methode über die Testseite auf. Beim Aufrufen der Webmethode wird auf Ihre Haltepunkte zugegriffen.

Sie können auch aus einer für die Laufzeit geschriebenen Anwendung in einen ASP.NET-Webdienst wechseln. Stellen Sie dazu sicher, dass Sie der Debuggerbenutzergruppe auf Ihrem Computer das Konto zum Ausführen von ASP.NET (i.d.R. ASPNET) hinzugefügt haben. Anschließend können Sie mit dem Debuggen der Web- oder Clientanwendung beginnen. Wenn Sie die Zeile erreichen, die den Webdienst aufruft, gehen Sie unter Verwendung des Befehls Einzelschritt im Debugger in die Funktion. Im Hintergrund geht der Debugger automatisch in den Webdienst.

Trennen in ASP.NET

Die Common Language Runtime ermöglicht Ihnen die Trennung von einem Prozess, ohne diesen dabei abzubrechen. Beim Debuggen von ASP.NET ist dies besonders hilfreich, da Sie eine Trennung vornehmen können und keinerlei Statusinformationen verloren gehen. Sie können die Verbindung zu einem Prozess trennen, ohne ihn abzubrechen, indem Sie im Menü Debuggen auf Debuggen beenden klicken. Standardmäßig trennt der Debugger beim Beenden des Debuggens eines ASP.NET-Projekts die Verbindung zum Prozess, ohne ihn jedoch zu beenden.

Debuggen von Visual C++-Anwendungen


Neben dem überarbeiteten Debugger zum Debuggen von Laufzeitcode enthält Visual Studio .NET auch einen verbesserten C++-Debugger. Visual Studio .NET unterstützt jetzt das Generieren von Minidumps für C++-Anwendungen und das Öffnen ihrer entsprechenden Dumpdateien (.dmp).

Ein Minidump ist im Wesentlichen ein Snapshot einer ausführbaren Datei, der zur Problemdiagnose an einen Entwickler gesendet werden kann. Weitere Informationen zu Dumps finden Sie in der Plattform-SDK-Dokumentation. Um Ihre Anwendung während des Debuggens als Minidump zu speichern, wählen Sie im Menü Debuggen den Befehl Dump speichern unter und geben dann einen Dateinamen für den Dump ein. (Sie können die Dropdownliste Dateityp ändern, um den Dump zusammen mit Heapinformationen zu speichern. Dabei wird jedoch eine umfangreichere Datei erstellt.) Dieser Dump schließt den Status der Anwendung ein und kann auf dem Computer eines anderen Entwicklers geöffnet und gedebuggt werden. Der Entwickler kann diese Dumpdatei in Visual Studio .NET öffnen und sich den ursprünglichen Programmstatus anzeigen lassen. Der Minidump speichert den Erstellungspfad der ausführbaren Datei. Wenn er auf einem Computer geöffnet wird, auf dem das Projekt erstellt wurde, zeigt er Ihnen automatisch Ihren Quellcode und Status an.

Der Entwickler kann den Dump auch auf einem Computer ohne entsprechende Binaries und PDB-Dateien öffnen. Er kann die Binaries und PDB-Dateien neben die DMP-Datei stellen oder sie im Dialogfeld Eigenschaftenseiten in der Tabelle Befehlsargumente angeben. Die Syntax sollte wie folgt aussehen:
MODPATH=C:\temp\xyz;d:\temp;f:\abc\temp

Beim Laden eines Dump führt das unter Befehlsargumente angegebene MODPATH-Argument den Debugger zum Speicherort der Binaries und PDB-Dateien des Programms.

Nachdem die Modulpfade definiert sind, muss der Entwickler in seinem Projekt nur noch F5 drücken, und der Programmstatus wird so angezeigt, wie er auf Ihrem Computer war. Der Entwickler kann zwar die Ausführung nicht fortsetzen, jedoch ihren Status untersuchen und Aufrufstapel zur Problemdiagnose anzeigen.

Keine zusätzlichen DLLs

Dank eines weiteren verbesserten Features brauchen Sie keine zusätzlichen DLLs anzugeben, um Haltepunkte in DLLs in Prozessen zu setzen, die auf Ihrem lokalen oder Remotecomputer laufen. Sobald Visual Studio .NET erkennt, dass die DLL geladen wird, bindet es jetzt die Haltepunkte dynamisch an die DLL. Sie brauchen nur noch F9 zu drücken oder einen Haltepunkt in dem Code zu setzen, den Sie debuggen möchten. Der Debugger bindet ihn dann, sobald die DLL geladen wird.

Anmerkung: Wenn Sie einen Haltepunkt hinzufügen, wird u.U. ein Fragezeichen angezeigt. Hierbei handelt es sich um einen Warnhaltepunkt, der darauf hinweist, dass der Code an der Stelle nicht geladen wurde. Wird der Code zukünftig geladen, wie es auch bei DLLs der Fall ist, wird das Fragezeichen aus diesem Haltepunkt entfernt. Trennen von einem Prozess

In der Vergangenheit wurden Visual C++-Anwendungen beim Debuggen beendet, wenn Sie den Debugvorgang beendeten. Jetzt können Sie den systemeigenen Debugger von Visual Studio .NET-Anwendungen unter Microsoft® Windows® XP trennen. In den Betriebssystemen Microsoft® Windows NT® 4.0 und Microsoft® Windows® 2000 ist dies ebenfalls möglich, allerdings müssen Sie dazu einen Dienst auf Ihrem Computer starten. Suchen und starten Sie im Dialogfeld Dienste den Visual Studio Debugger-Proxydienst. Nach dem Start dieses Dienstes können Sie Ihren Prozess anfügen oder starten. Anschließend können Sie die Verbindung zu systemeigenen Prozessen auf diesen Betriebssystemen trennen.

Einzelschritt in spezielle Funktionen

Ein weiteres tolles Feature des Debuggers ermöglicht es Ihnen, in eine spezielle Funktion zu gehen. Wenn Sie in einer Zeile mit mehreren geschachtelten Funktionen oder einem Funktionsaufruf sind, der Sie zu einem Einzelschritt in einen Konstruktor veranlasst, klicken Sie mit der rechten Maustaste auf die Zeile, und wählen Sie im Kontextmenü die Option Einzelschritt in Angabe. Daraufhin können Sie die gewünschte spezielle Funktion für den Einzelschritt auswählen. Somit sind Sie in der Lage, für Sie unwichtigen Konstruktorcode zu vermeiden und können stattdessen direkt in die Funktion gehen, die Sie debuggen möchten.

Abbildung 3. Einzelschritt in Angabe

stepintospecific

TSQL-Debuggen


Eines der weniger bekannten Features von Visual Studio ermöglicht das Debuggen gespeicherter Prozeduren, Funktionen und Trigger in SQL Server 7.0 und 2000. Es ist in der Enterprise Edition von Visual Studio .NET enthalten.

TSQL-Routinen können auf zwei Arten gedebuggt werden:

  • Über Server-Explorer

    Stellen Sie über Server-Explorer eine Verbindung zur Datenbank her. Öffnen Sie die gewünschte gespeicherte Prozedur, klicken Sie mit der rechten Maustaste, und wählen Sie den Befehl Einzelschritt aus. Fertig! Jetzt können Sie die gespeicherte Prozedur aufrufen und deren Ausführung überprüfen.

  • Durch Zugriff auf Haltepunkte in gespeicherten Prozeduren, die in einer Anwendung aufgerufen werden

    Als weitere Methode können Sie die gespeicherte Prozedur debuggen, wenn sie über eine Clientanwendung aufgerufen wird. Dazu müssen Sie das SQL-Debuggen in dem Clientprojekt aktivieren, das die gespeicherten Prozeduren aufruft. Sie setzen diese Option in den Eigenschaften Ihres Projekts unter Konfigurationseigenschaften und Debuggen. Öffnen Sie nach dem Start der Anwendung den TSQL-Routinecode in Server-Explorer, und setzen Sie dort einen Haltepunkt. Drücken Sie F5 in Ihrer Anwendung, um in Server-Explorer auf den Haltepunkt zuzugreifen. Diese Art des Debuggens funktioniert auch in Webanwendungen, die gespeicherte SQL Server-Prozeduren aufrufen.

Automatisierungsmodell


Visual Studio .NET verfügt über ein leistungsstarkes Automatisierungsmodell. Es ermöglicht Ihnen, Makros zu schreiben, die Ihre täglichen Aufgaben in der Umgebung automatisieren. Der Visual-Studio-.NET-Debugger verfügt zudem über Automatisierungsschnittstellen, mit denen Sie auf unterschiedliche Debugginginformationen zugreifen können, z.B. das derzeit ausgeführte Programm, seine Aufrufstapel, Threads usw. Visual Studio .NET enthält mehrere Beispielmakros, die Sie durch Öffnen des Knotens Beispiele in der Verzeichnisstruktur des Makro-Explorer anzeigen können. Unter den VSDebugger-Beispielen werden verschiedene Beispiele angezeigt, die das Debuggerautomatisierungsmodell verwenden. Einer meiner Favoriten ist DumpStacks - ein Beispielmakro, mit dem Sie die aktuellen Aufrufstapel abrufen können, die mit sämtlichen Threads in Ihrer Anwendungen verknüpft sind. Diese Informationen sind speziell für Fehlerberichte sehr hilfreich.

Installieren von Komponenten zum Remotedebuggen


Häufig möchten Benutzer eine Anwendung, die auf einem separaten Computer ausgeführt wird, remote debuggen. Visual Studio .NET enthält ein paar Komponenten, mit denen Sie, wenn sie auf einem Remotecomputer installiert sind und Sie über die ausreichenden Berechtigungen verfügen, Prozesse auf diesem Computer remote debuggen können. Diese Installation ist besonders nützlich, wenn Sie Visual Studio .NET nicht komplett auf einem Remotecomputer installieren möchten. Die Installation dieser Komponenten wird über den Link Remotekomponenten-Setup unten in der Seite Visual Studio .NET Setup auf der CD gestartet. Klicken Sie auf diesen Link, um die Komponenten zum Remotedebuggen entweder für alle Sprachen zu installieren, die über DCOM mit dem Debugger kommunizieren, oder nur für C++ (wenn Sie lieber mit der Visual C++ 6.0-Methode zum Remotedebuggen über TCP/IP arbeiten).

Schlussfolgerung


Dies ist nur eine kurze Übersicht über die neuen Debugfeatures von Visual Studio .NET. In der Dokumentation zu Visual Studio .NET wird eine Vielzahl weiterer leistungssteigernder Features ausführlich behandelt. Wir wünschen Ihnen gutes Gelingen beim Entwickeln Ihrer nächsten Anwendung mit dem Visual Studio .NET-Debugger!


Anzeigen: