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:

image

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 Smiley 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!

image

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.

image

Der Breakpoint ändert dann seine Darstellung:

image

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:

 

image

 

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:

image

 

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).

image

Tracepoints erkennen wir optisch an der rautenförmigen Darstellung.

image

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.

Comments (4)

  1. Gibt es für das Kontextmenü echt keinen Shortcut? Finde ich ziemlich schade 🙁

    (und für jeden Befehl einen eigenen, noch freien, zu finden habe ich bisher auch keine Lust gehabt)

    Die Bedingungen benutze ich schon seitdem ich VS kenne (zumindest gefühlt ^^), allerdings sollte man sich nicht wundern, wenn die Ausführung langsamer wird, besonders in Schleifen. So eine Abfrage dauert relativ lange, wodurch beim Iterieren von 1000+ Elementen schon mal einige Sekunden verstreichen können. Eventuell lohnt es sich dann doch mal in den Code einzugreifen, denn das kann wirklich deutlich schneller gehen.

  2. @Koopakiller: Ich kenne leider keinen Shortcut – sobald ich einen in Erfahrung bringe, wird er gepostet!

    Das Feature ist wirklich schon sehr lange in VS, ist aber noch nicht überall bekannt – insofern: Bitte weitererzählen! 🙂

  3. Notëis sagt:

    Nun ja. Ist zwar kein "Short"cut, aber gehen würde: Menü-Taste + h + b + b + Enter

    Nur um an die Existenz dieser ja sooo häufig benutzen Taste zu erinnern. 🙂

  4. Ehe ich mir das gemerkt habe bin ich wahrscheinlich mit der Maus schneller :/

    Im Moment hoffe ich auf VS 2015, dort wird die Tastatursteuerung dafür vielleicht endlich etwas verbessert.