Set breakpoints on auto-implemented properties with Visual Studio 2015
November 14, 2014
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.
I think better will be add support for call events from Auto properties like
INotifyPropertyChanged
public object Something
{
get;
Set; // or set (d=> {possible cusstom code with return and modified 'value'} );
NotyfypropertyChanged(nameOf(Something)); // or notify(nameOf(Something))
}
Hi Daniel,
How can you do the same with VB.Net?
Public Property MyProperty() As Boolean
Thanks,
Dennis
@Dennis: Visual Basic currently does not support placing breakpoints in source for that syntax. This is a limitation of the way the Visual Basic compiler generates the auto-property so I would encourage you to file the issue with them on their GitHub issues page github.com/…/issues
You can workaround this in the debugger if you need to break on the auto-implemented property by creating a function breakpoint (blogs.msdn.com/…/function-breakpoints.aspx) where the function name will be get_<property_name> or set_<property_name> (so in your example above to set a breakpoint on the assignment you would create a function breakpoint for "set_MyProperty"). When you break there will however be no source associated with the function (which is why you can't set breakpoints from the editor).
For VS 2013, once you set the break-point as shown, you need to the check-box "Tools -> Options -> Debugging -> General -> 'Show disassembly if source is not available'" ticked for it to break correctly, otherwise you will get a 'Source Not Available' message.
Also, for me it showed the break in assembly code, if you want to see the break in source code, go to the relevant method in the Call Stack window, right-click it and choose 'Go To Source Code'.
The above comment only applies when the form of the property is like:
public string MyProperty { get; set; }
i.e. when you don't set the 'get' or 'set' method, or associated private types, in your code.