Set breakpoints on auto-implemented properties with Visual Studio 2015

Anisha Pindoria

Ask a room of developers what is the first concept that they think of when they think about debugging and most of them will say: breakpoints. That is why with Visual Studio 2015 we significantly improved the ability to configure breakpoints with conditions and actions. Given how easy it is now to configure breakpoints, we know you’ll be more upset if you accidentally delete one of them, so we also offer undo capability – when you remove a breakpoint by accident, just Ctrl+Z to bring it back with all its settings.

In this post, I’ll share another smaller breakpoint enhancement: the ability to place breakpoints on auto-implemented properties.

The problem (up to VS2013)

C# supports auto-implemented properties. While debugging, it is sometimes useful to break when a property is accessed, especially when it is called from multiple places and it is tedious to track them all down to set a breakpoint on all the caller sites. So considering the following example…

namespace MyName {
  class Program {
    static bool MyProperty {
      get; // line 4
      set; // line 5
    }
    static void Main() {
      if ((new System.Random()).Next(3) == 1)
        MyProperty = true; // line 9
      else
        MyProperty = false; // line 11
      System.Diagnostics.Debugger.Break(); // line 12
    }
  }
}

…if you try to set a breakpoint on lines 4 or 5, the breakpoint will unfortunately move to the closest place where we think it will bind. Aside: where we think it will bind differs depending on whether you set it at design time or at runtime which is when we have more info. Either way it will not break, and when you F5 it you’ll break instead directly on line 12.

First I’ll share the VS2013 workaround, and then the VS2015 solution – feel free to skip to the next section with the VS2015 solution if that’s all you care about.

The Visual Studio 2013 solution – function breakpoints to the rescue

Other than tracking down all the caller sites, or changing the auto-implemented property to be a full property with an explicitly visible backing field in your code, the solution is to use a Function Breakpoint. You don’t know about function breakpoints you say? Go read about them and I’ll wait here for you.

So from the Breakpoints window set a new Function breakpoint (Ctrl+B) as per the following screenshot (in this case simply entering set_MyProperty would also work)

Now when you F5 the debugger will break on line 9 or 11, dependent on which one was the lucky one making the call.

Note: if you have turned off Just My Code (JMC) from Debug->Options, or you have checked the “Show External Code” option in the Call Stack window, then you’ll need to navigate in the Call Stack to the top most user code function which will be Main, and then you’ll see it on line 9 or 11.

The Visual Studio 2015 solution – it just works

In Visual Studio 2015, simply set the breakpoint on line 4 or 5 and it works. It will break there, and JMC/External Code considerations are not relevant. To navigate to the caller, simply go down the stack by one stack frame and you’ll land on line 9 (or 11).

You can thank the Roslyn team for fixing this, and we are excited that we are closing yet another uservoice item with this release. As always your feedback is welcome via our MSDN forum.

Anisha Pindoria Senior Program Manager, Azure DevOps

Follow