Marko hat in seinem Blogeintrag Mitte des Jahres schon gezeigt, wie man mit Hilfe von Detail Formatern die Ausgaben von Eclipse während des Debuggings vereinfachen oder besser lesbar machen kann – ähnliche Funktionalitäten gibt es auch im Visual Studio.

Bei Objekten wird im Debugger in der Regel im Feld Value nur der Typ des Objekts angezeigt. Mit Hilfe des Plus-Zeichens kann man dann durch die Eigenschaften navigieren.

Bei nur wenigen Eigenschaften ist das noch recht übersichtlich. Aufwändiger wird es, wenn man eine komplexe Objektstruktur hat.

Mit Hilfe des DebuggerDisplay-Attributes kann man die primäre Ausgabe noch anpassen und so direkt die wichtigsten Eigenschaften sichtbar machen ohne das Objekt im Debug-Fenster aufklappen zu müssen.

Wer kennt das nicht? Man debuggt  sich Zeile für Zeile durch den Code um Fehler in komplexen Algorithmen zu finden.

Das Auslesen von primitiven Datentypen oder Strings klappt ziemlich gut. Wenig hilfreich ist allerdings die Darstellung von Kalenderobjekten.

Mit Hilfe der in Eclipse angebotenen DetailFormater lassen sich Objekte im Debug-Modus beliebig formatieren. Für ein Objekt vom Typ “java.util.GregorianCalendar” könnte die Formatierung folgendermaßen aussehen: this.getTime().toString();

Ergebnis: Fri Jul 17 22:46:07 CEST 2009

Diese Darstellung ist dann schon deutlich lesbarer.
Auch für komplexere Datenstrukturen könnte es hilfreich sein, die wichtigen Informationen auf einem Blick zu sehen.

So funktioniert es

1. Einstellungsdialog öffnen (Menü “Windows/Preferences” Pfad “Java/Debug/Detail Formaters”)
2. Button “Add” klicken
3. Eintragen von java.util.Calendar in das Feld “Qualified type name” field
4. Eintragen von Enter this.getTime().toString()
5. Button “OK” klicken

In Visual Studio 2005 gibt es leider einen kleinen Bug in den “Extensions for WF”. Das Debuggen von Workflows, also nicht des Quellcodes, funktioniert oft nur schlecht oder garnicht. Häufig stürzt das Visual Studio sogar ab, wenn man versucht den Debugger an einen Prozess zu hängen, der Workflows verwendet. Einen solchen Prozess erkennt man recht leicht, indem man einen Blick auf den Typ wirft. Steht dort u.a. “Workflow” (siehe Abbildung) sollte man sich besser nicht an den Prozess hängen.

Verhindern lässt sich dieser Effekt indem man das Visual Studio bereits an den Prozess hängt, bevor die Assembly des Workflows geladen wurde, wobei ggf. vorher ein iisreset durchgeführt werden muss. Sobald die Assembly geladen wurde, lässt sich der Quelltext wie gewohnt debuggen.

Endlich Schluss mit “An unexpected error has occured” ? (Hoffentlich )

Im Blog vom SharePoint Team ist ein Debugger Feature vorgestellt worden. Damit kann man einen Debugger an Teamsites hängen.

Das Feature kann bei CodePlex heruntergeladen werden.