Debugging properties [Kit George]

Ilya Ryzhenkov Enquired:

Is there any method to detect (not switch off) if property getter is being called by debugger and not user code? This would help to debug delay-loaded properties and many other stuff. For future versions, something like Debugger.IsGettingProperty would be great.

Ilya, there is no way to do this from managed code today. We're hesitant to encourage folks to have their properties behave differently when called by a debugger than when not - we can see a lot of very hard-to-find issues coming from that.

However, we’ll consider it for a future release. Thanks for the suggestion.

Comments (4)

  1. Anonymous says:

    Actually, there is at least one method, pretty complex, involves VS automation. But generally debug mode lacks communication to code. They say Whidbey gives some improvements, but what I’m looking for is more solid debugger support from within the code. This is primarily required for library developers, so they provide good support for debug time, like they can do for design time. Here is short list for proposed features:

    1. Give developers opportunity to return format for previewing objects, like we currently do with mcee_cs.dat. Attribute will probably make it, but imperative way would be nice too (like DefaultValue in debugger backed with ShouldSerialize and Reset methods).

    2. Give opportunity, as in original inquery, to differentiate between run and debug time. Your argument about "hard-to-find issues" is applicable to design time detection as well, but it’s still there. Also, having "lock" statements makes dead-locks possible, sometimes very hard-to-find issue, but again it’s there. This is an advanced feature and people using it should be just warned about consequences. Like wise man said: "Simple should be simple, advanced should be available" (not a citation, up from my memory)

    3. Give opportunity to hide properties from debugger. Something like DebuggerVisibility.Hidden attribute.

    All in all I seek better debugging support and commnuication between smart debugger, developer and the code.


  2. Anonymous says:


    – Keep an eye out for suggestion 1 and 3 in the near future

    – For suggestion 2, we’ve taken that on board, and will hope to address it in a future release

Skip to main content