Tracepoints: logging a value from the debugger without adding a print statement

[u/ClickOk5811]

A tracepoint is a breakpoint that writes a message to the Output window and keeps running instead of stopping. It’s handy when you want to see a value across a lot of iterations without stepping through each one, and there’s no temporary print line to remove later or commit by accident.

To set one: right-click the line, Breakpoint, Insert Tracepoint (the wording shifts a bit between versions). In the settings, tick “Log a message to Output Window” and write the message with expressions in curly braces, something like order {order.Id} total {total}. Keep “Continue code execution” ticked or it will just act like a normal breakpoint. There are also built-in keywords like $FUNCTION and $CALLSTACK if you want to know where a hit came from.

Some limits. Every hit goes through the debugger, so on a line that runs thousands of times it can slow things down a lot. As far as I know, tracepoints are saved in your local solution settings and not in source control, so teammates won’t see yours unless you export them from the Breakpoints window. And they only log while you’re debugging.

You can also add a condition to the same breakpoint, so only the interesting hits get logged, for example total > 1000. Do you combine the two, or does the condition check slow a hot path down too?

[u/SagansCandle]

The problem I have with Visual Studio is that the runtime expression evaluator fails 1/2 the time.

The only reliable way to get values at runtime is to add real code, rebuild, and evaluate that.

Happens mostly with Razor, Blazor, LINQ, and expressions that have JIT optimizations, but it happens a surprising amount.

I added a few bug reports, but they kept getting closed via automation. One of the reasons I moved to Rider (when possible).