Autos window and mouse hover does not work for properties

Question

The debugger's "Autos" window and "mouse hover" does not respect the debugger attributes DebuggerDisplay, DebuggerBrowsable, and DebuggerTypeProxy for properties. If a program is stopped in the debugger then pointing on a property will have the debugger execute the code for the property and thereby trigger side effects. See the code snippet below.

You can turn off Tools | Options | Debugging | "Enable property evaluation and other implicit function calls", but then you cannot see values of automatic properties at all. I don't find this a way to go.

My real issue is that I have a WPF application which binds to data in a model, which directly reads values from a WCF service. Debugging these data properties makes the debugger hang until the service connection times out and invalidates the channel and makes Resume program fail.

So my question is:
Are there other ways to circumvent this issue?
Will this issue with the debugger be solved in 2010?

I am using Visual Studio 2008 Professional SP1 and the hotfix "Updates for Visual Studio 2008 SP1 debugging and breakpoints" from http://support.microsoft.com/kb/957912

Example code snippet:

    class Program
    {
        static void Main(string[] args)
        {
            Data data = new Data();
            int value = data.Value;
            // Breakpoint on the following line: The Autos-window executes data.Value - see the Debug output
            Console.WriteLine("Value = " + value);
            // Breakpoint on the following line: data.Value is out of scope for the Autos-window
            // Hover the mouse over data.Value  executes data.Value - see the Debug output
            Console.WriteLine("Done with Value = " + data + "; Expected to be 1!");
        }
    }

    //[System.Diagnostics.DebuggerTypeProxy(typeof(DataProxyDebugView))]
    public class Data
    {
        private int valuePropertyCounter;

        //[System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableState.Never)]
        [System.Diagnostics.DebuggerDisplay("Not available in debugger")]
        public int Value
        {
            get
            {
                System.Diagnostics.Debug.WriteLine(">> Data.Value just called!");
                ++valuePropertyCounter;
                return this.valuePropertyCounter;
            }
        }

        public override string ToString()
        {
            return valuePropertyCounter.ToString();
        }
    }

Answer 1

Welcome to MSDN forum and thanks for your feedback.

Currently, we have no attribute which can control the evaluation of property. DebuggerDisplay and DebuggerTypeProxy only change the display format of property or type. DebuggerBrowsable can hide the property when user browse the object.

As you already found, turn off Tools | Options | Debugging | "Enable property evaluation and other implicit function calls" is the only way to stop property evaluation in debugger. But you can still force the property to evaluate in watch window. Watch window allows user to refresh the property.

VS2010 behaves same as 2008.

If you want to change the current behavior, you can tell product group by submiting a suggestion to http://connect.microsoft.com.

Have a nice day.

Hongye Sun [MSFT]
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg @ microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Thanks for the reply.

The Locals-window populates the values for properties by reading the Debugger attributes and NOT executing/evaluating the code. The Autos-window and mouse hover executes/evaluates the code. As a user I expect the 3 scenarios to behave the same.

I will submit something.

By the way Visual Studio Express behaves the same way for mouse hover.

Best regards Gorm

Answer 3

Hi Gorm,

In response to "My real issue is that I have a WPF application which binds to data in a model, which directly reads values from a WCF service. Debugging these data properties makes the debugger hang until the service connection times out and invalidates the channel and makes Resume program fail."

Is the WCF service running under the debugger as well?  If it is, your issue is that the WCF service is paused just like the WPF application from which you are trying to evaluate the property.  When you evaluate the property that calls the WCF service, the service cannot respond because it is in a break state. 

If that sounds like it is the case, you may want to try the Visual Studio 2010 Beta2, as we have added a feature that allows other threads to run so that properties can be evaluated in this scenario.  If this sounds like it may be the issue, and you are interested in trying the Visual Studio 2010 Beta2, I'll be happy to provide more information.

---

Best Regards, Andrew Hall. Visual Studio Debugger.

Answer 4

Hi Andrew,

Thank you for answering.

My WCF issue is a little more complicated than that, as it also hits me if the WCF service runs in a separate process. Further digging has narrowed down the issue, so a short description could be: A WPF application calls a WCF singleton service having a dublex channel (the callback is not invoked though). When the debugger evaluates the property (calling the WCF service) it times out. Resuming the application execution makes the UI thread terminate and the application hang. A similar Forms application can be debugged.

Best regards Gorm Vognsen Jensen

Answer 5

Hi Gorm,

It sounds like the Visual Studio 2010 feature we call "Thread slipping during func-eval" would solve this problem for you (since it sounds like a separate thread is responsible for processing the callback).  In order to use this feature in 2010, place a call to "System.Diagnostics.Debugger.NotifyOfCrossThreadDependency();" in the property that makes the WCF call.  This prevent the property from automatically evaluating (an icon will appear in the watch window and a pinned/floating DataTip requiring a user click to force evaluation, and will prevent the property from being evaluated in a standard DataTip or the immediate window at all), and when the icon is clicked, it will allow the threads to run so that the evaluation can occur. 

If you choose to use this feature, please read the warning tooltip that appears on the evaluation icon that is clicked, as it does actually run the code, so any side effects of running those threads code will occur and change your application state based on the changes made by the running threads.

---

Best Regards, Andrew Hall. Visual Studio Debugger.

Answer 6

Hi Andrew

You are right, it may be a solution. However, I will not test it right now.

Thank you for following up.

Best regards Gorm Vognsen Jensen

Answer 7

I found a way to avoid the deadlock and the following crash. Set the SendTimeout on the binding (Channel) lower than the timeout, which the debugger uses when evaluating the expression (property). It could be 500 milliseconds. The code when constructing the connection (binding) could look like this:

if (System.Diagnostics.Debugger.IsAttached)
{
    binding.SendTimeout = TimeSpan.FromMilliseconds(500);
}

In the debugging session wil the debugger show this string instead of the value:

'this.Value' threw an exception of type 'System.TimeoutException'

Best regards Gorm Vognsen Jensen