Auto-implemented properties and breakpoints

Question

I like the shorter syntax of auto-implemented properties but it seems that there is no way to set a breakpoint on such property and monitor when the value of the property is modified (or is accessed). To enable breakpoints the source code must be rewritten and old syntax of property declaration must be used. But sometimes code cannot be modified so it seems there should be another, simpler way to set a breakpoint. I found no warning in documentation that using auto-implemented properties affects debugging.

 

Is this a bug in VisualStudio 2008 or in C# compiler? Or is there any method to enable such breakpoints?

 

Thanks in advance.

Answer 1

Hi,

As you can read in this post, it does make sense (modified slightly):

When you use automatic properties and you set the same breakpoint on accessing the property, you notice that nothing actually happens, which makes sense because there is only direct IL code, generated by the compiler behind the setter implementation, and no C# code, so the compiler has nowhere to go!

 

Using watches might help you somewhat while debugging automatic properties, but it's not the same debugging experience as the breakpoint on the getter or setter.

Hope this helps

Answer 2

Rick van den Bosch wrote:

Hi, As you can read in this post, it does make sense (modified slightly): When you use automatic properties and you set the same breakpoint on accessing the property, you notice that nothing actually happens, which makes sense because there is only direct IL code, generated by the compiler behind the setter implementation, and no C# code, so the compiler has nowhere to go!

Thank you for the answer, but I still think the lack of breakpoints on automatic properties is a bug. Yes, you would not be able to step into the code (there is no C# code anymore), but still it should be possible to set a breakpoint on such statement. The compiler should map get and set statements to beginnings of hidden methods (and maybe add DebuggerStepThrough attribute to force explicit breakpoints). With the current implementation there is no way to be notified just after an automatic property has been changed.

 

Rick van den Bosch wrote:

Using watches might help you somewhat while debugging automatic properties, but it's not the same debugging experience as the breakpoint on the getter or setter. Hope this helps

 

Unfortunately watches can only notify you that the watched variable has been modified. There is now way to find out what code changed the property value, no way to look at the program execution context during property modification.

 

The ability to set breakpoints on setters was frequently mentioned as one of the reasons why properties should be used instead of fields. Now we have new properties, that from the debugging point of view seems no better than plain-old fields.

 

  

Answer 3

incola,

Have you tried setting the breakpoints at the curly braces? This is a host in the dark -- I haven't tried it yet but it might work, i.e.., if you have breakpoints at the curly braces then at least you know that the code has entered or exited the getter/setter.

And in a way you are right... automatic properties are no different from fields.

Answer 4

I am sorry but that's the limitation of the automatically implemented properties for now. I will appreciate if you submit a suggestion to http://connect.microsoft.com/visualstudio, where your idea might be taken into account in future releases.

 

Answer 5

setting breakpoint directly seems not supported, but looks like setting breakpoint using function name using fully qualified name works.

 

ex)

class C .. {

public int A { get; private set; } }

 

create function name breakpoint on C.A

---

HeeJae Chang

Answer 6

As a follow up to HeeJae Chang's answer, you can set a breakpoint on a function name by following the example on the following page:

http://msdn.microsoft.com/en-us/library/15d1wtaf.aspx