Visual Studio Tipps und Tricks, Teil 40: Tracepoints! Tracepoints? Tracepoints!

Der 40. Tipp der Serie widmet sich einem der best kept secrets in Visual Studio. Nicht, dass es irgendjemand absichtlich versteckt hätte oder geheimhalten würde. Aber es ist immer wieder so: Tracepoints erfreuen sich nicht gerade großer Bekanntheit.

Ich denke, jeder von uns kennt Breakpoints. Diese roten Kugeln am linken Rand. Falls nicht, möchte ich hiermit zusätzlich Verwirrung stiften und auf den Blogpost hinweisen, der erklärt, wie man auch ohne Breakpoints breaken kann.

Aber zurück zum Thema: Breakpoints sind also bekannt und sehen ungefähr so aus:

Man setzt sie mit F9 oder mit Mausklick in die dunkelgraue Seitenleiste. Wenn wir den Code jetzt ausführen, wird die Ausführung hier anhalten, wir können Werte von lokalen Variablen checken etc, etc. Alles wie gewohnt.
Nun geschieht ein kleines Wunder Wir befinden uns an einem Punkt in der Benutztung von Visual Studio, wo ausnahmsweise die Mausnutzer einen kleinen Vorteil gegenüber den Tastatur-Shortcut-Junkies haben. Denn – mal ehrlich – wer würde schon auf die Idee kommen, diesen komischen roten Knubbel einfach mal mit der rechten Maustaste zu klicken?

Let’s do it!

Was sehen unsere müden Augen? Ein Kontextmenü, das es wert ist erforscht zu werden. Ich will in diesem Blogpost nur auf die für mich relevantesten Möglichkeiten eingehen.

Bedingungen

Wir können über “Condition..” eine Bedingung angeben, unter der hier tatsächlich angehalten wird. Das ist angenehm, wenn wir in längeren Debuggingsessions immer wieder auf den Breakpoint treffen, der eigentlich nur unter ganz bestimmten Bedingungen von Bedeutung ist. Wir können hier auf lokale Variablen zugreifen und einfach Werte vergleichen.

Der Breakpoint ändert dann seine Darstellung:

Zähler

Wir können über “Hit Count…” eine Zählfunktion einbauen und dafür sorgen, dass der Breakpoint eben nicht immer, sondern nur beim x-ten mal anspringt. Schon mal eine Schleife über 100.000 Datensätze gedebugged, die komischerweise immer beim 999.998 Durchlauf abschmiert? Da wird das Debuggen zur Qual, wenn man immer einzeln weiterklicken muss. Hier ist die Lösung – einfach den Hit Count entsprechend nach oben kurbeln:

Filter

Die Filterfunktion erlaubt es uns den Breakpoint nur zu zünden, wenn bestimmte Umgebungsparameter zutreffend sind. Das ist insbesondere bei Remotedebugging-Szenarios cool, wenn man z.B. nur auf bestimmten Maschinen debuggen möchte:

Tracepoints

Ja und dann gibt’s noch das Tracen: Wir können festlegen, was passieren soll, wenn der Tracepoint erreicht wird, in dem wir eine “When Hit…”-Aktion angeben. Was soll passieren? Nun, wir könnten ja z.B. eine Debug-Message ausgeben inklusive einem aktuellen Variablenwert. Schön ist dabei, dass wir die Ausführung weiterlaufen lassen können (wenn wir wollen).

Tracepoints erkennen wir optisch an der rautenförmigen Darstellung.

Insgesamt viele Möglichkeiten ohne Eingriff in den Quellcode die Debuggingsessions deutlich zu vereinfachen.

Tl;dr

Ein Rechtsklick auf einen Breakpoint eröffnet neue Horizonte!

Kurzer Text am Rande:

Dieser Post ist Teil einer längeren Serie, in der ich ein paar der vielleicht nicht ganz so bekannten Features von Visual Studio vorstellen werde. Ich hoffe, für Euch ist der ein oder andere Kniff dabei, den Ihr noch nicht kanntet. Und wenn ihr ihn doch schon kennt: Seid stolz auf Euch und verratet den Trick auch dem Entwickler neben Euch.