A Behavior Change in Visual Studio 2013 .NET Breakpoints

One of my favorite tricks is to use Visual Studio breakpoints to call a method to force state changes when testing code. There’s just some times where calling a method at a breakpoint is the fastest way to create a test. To call a method at a breakpoint, set a regular location breakpoint, right click on the breakpoint circle in the gutter, and select Condition. That will get you the wonderful Breakpoint Condition shown below.

The Visual Studio team didn’t put full Intellisense in because they were feeling wild and crazy one day. They want you to call methods from breakpoints. If this technique is new to you, I can already hear your mind racing away with ideas on how it can help you.

There has been a change in the implementation of how methods are called from conditional breakpoints in Visual Studio 2013. Let’s take a look at how things worked in Visual Studio 2012 first. Here’s a method I want to call from the a conditional breakpoint, which you can see sets state.

I’ve set a conditional breakpoint in Visual Studio 2012 and using an instance of the class am calling the CallFromBreakpoint method.

Note that you can call private methods all day long in the conditional breakpoints but the Intellisense in the Breakpoint Conditional dialog only shows you public methods. In the debugger everything is essentially public. Obviously, you’ll always keep these special debugger call only methods private.

After our breakpoint triggers in Visual Studio 2012 you can see in the Watch window the CallFromBreakpoint method executed and changed the state of a, the object itself.

Running the exact same program in Visual Studio 2013 with the same conditional breakpoint set shows a different story.

The breakpoint stopped because CallFromBreakpoint returned true, but the object state didn’t change. That was kind of weird and not what I expected. What you’re seeing is that starting with Visual Studio 2013, the debugger has switched to a new managed engine. One of the new features is that instead of executing methods called on conditional breakpoints inside the debuggee (your program), like was done in Visual Studio 2012, they now use a new IL interpreter in the debugger. There’s good reasons for that with the main reason being that it’s far safer because the less you mess up the debuggee from the debugger the better. If you follow this link, you can see how to revert to the old engine to get the Visual Studio 2012 functionality in Visual Studio 2013, but as the link warns the old engine will be gone in the future.

Fortunately, in Visual Studio 2013 and future versions of Visual Studio, we can still call methods from the debugger that execute in the debuggee to change state. The trick is to use Trace Points instead. In the When Hit dialog below, I’ve called a.CallFromBreakpoint() inside the curly braces to ask for the evaluation.

If you have the Visual Studio hosting process turned on in the project Debug options for console, Windows Forms, or WPF applications, this trick will not work. You will need to turn it off but that won’t change anything about your application debugging experience unless you are using Click Once security settings. One thing we have lost by using Trace Points is that we no longer can do logic in the called method to return true and break into the debugger and thus control breaking or skipping the breakpoint. Trace Points are either on or off.

Now you all know a little more about how the debugger does its magic and how you can work around the new debugging engine to change your state for testing in the debugger. If you’d like to learn a ton more awesome debugging tricks for your .NET applications, take a look at my Mastering .NET Debugging series as WintellectNOW. You can get two weeks free usage with the promo code JOHNR-2013.