Category: Visual Studio

Tracepoints in Visual Studio is a less known feature which really could save lot of our time in debugging .NET applications.

Let us just get straight into it.

Consider the following simplest loop (and simultaneously think about the most complex loop you have ever written). The intention here to determine the value of i and j at the end of each iteration of the for loop on the debug time. There is a breakpoint on the line 23:-

Now right click on the red dot and choose “When Hit”:-

[In VS.NET 2008,you can insert a tracepoint by right clicking on a line and choose Breakpoint > Insert Tracepoint]

And you should be presented with the following dialog:-

Check the checkbox “Print a message” and that would enable the textbox immediately below it. Notice that the “Continue Execution” checkbox gets checked too. Leave that as it is. You can place whatever debugging code to print the values of the in-scope variables on run time. For this example, we put the following:-

Notice the i and j in curly braces and that’s how the variables are represented here. You can place any in-scope variable on that line. That could be a value type variable like i and j or any of your in-scope class’s property or any in-scope FCL object’s property (e.g.XmlDocument.InnerXML).

When you click “OK”, the breakpoint red dot symbol changes to a diamond shaped one and that’s our tracepoint.

Before you do anything, just make sure you have the output window visible [Choose the menu View > Output OR Ctrl+W,O] and start the project with debugging.

You should see the following in your output window. If you see, we could print the values for the entire execution without changing the program.

Tracepoints behave just like breakpoints so we can take the liberty of calling them an extension of breakpoints.You can disable them, delete them, build the solution in the release mode when you don’t want them just like breakpoints.

If you are still not convinced, think of the following:-

a) If you would have added a “watch” for i and j, you could see the value of i and j, however, that would have only been the current value not their values for the entire execution.Tracepoints do exactly what watches don’t do for you.

b) If you could have put the Debug.WriteLine() statement, to print the variable values, you have this maintenance of removing them and I am talking about those large sized projects you are working/worked on.

c) If you could just have a breakpoint placed over and you wanted to do F5 (never mind million number of times) and you have this nested loop, you always wander around the code placing the cursor on the variables on the outer loop to see its value [because you forgot to place a watch on that J]. Then you forget what was the value of the variable in the previous iteration of the for loop, so you either start the execution again or change its value in the immediate window and so on. I have seen this many times and have done that too and I think it wastes some real good proportion of our time which rather should get utilized in better portion of coding.

Conclusion:-
While the breakpoints and watches etc. have still their place, Tracepoints help us quickly tracing and evaluating our program and are good to add in our debugging armory.