As I am sure everyone reading this article knows, the CLR support 'properties', which is a way of making function calls look like a variable read or write. These have some problems for debuggers, mostly because in order to evaluate a property, the debugger has to execute code inside the debuggee.

The biggest problem is that side effects of properties can cause different behavior inside the debuggee (application being debugged). This is more likely to be a problem if the user's code implements properties (as apposed to code inside the .NET Framework), since you are probably using the debugger to figure out why your code doesn't work. However, by debugging the code, the debugger can execute properties, which can cause the bug to go away. To make matters worse, even if you set a breakpoint on the property, you won't hit it. If you think about it for a while, this makes sense. If you had 'this' expanded in the watch window, we would infinitely go into break mode.

Another problem is that property evaluation is slow. Setting up the debuggee to run code is much slower then reading a bit of memory out of the debuggee. Complex properties can make the debugger look hung.

A third problem is that the debuggee may not be in a safe place to execute code. If some other thread has stopped after taking an important lock, then evaluating the property will just hang. Once the code is hung, it may be difficult or impossible to restore the state of the debuggee. This problem is going to be more important going forward because we will by trying to run less of the debugger inside the debuggee.

One last problem is that properties often expose the same value as a member variable. For my code, I would prefer to see 'm_Foo' then 'Foo' in the watch window. Having both is redundant.

Property evaluation can be turned of by disabling the option 'Tools->Options->Debugging->General->Allow property evaluation in variables windows'. However, this is kind of a sledge hammer approach. I would like to see an option where I don't see properties in my own code, and I don't see private member variables of types that aren't my code. This way, if I am looking at a .NET Framework type, it looks like the interface I use to program to. If I look at my own type, I don't see all those redundant properties. Maybe someday we will do this. What do you think?

One last note: I would like to make a recommendation to stop running complex code inside a property. I have heard of code which does network I/O or spins up threads inside of properties. This code is a bad idea in general, but it makes debugging your code significantly more difficult. In Whidbey, you will be able to add an attribute to these properties to tell them to not evaluate. That's a start.