Why does Visual Studio fail to set a conditional breakpoint on this simple C# property?

Question

In my C# object, I set a conditional breakpoint with the condition value == "Status" in the setter of this property. Normally it's decorated with a PostSharp aspect, but I've commented that out in this case, and it's still having trouble.

public virtual string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value; // breakpoint here
    }
}

The first time execution reaches the breakpoint, VS displays an error:

Visual Studio MessageBox

EDIT - for searchability, the message is this:

The following breakpoint cannot be set:

At (file).cs, line 137 character 17 ('(class).Name', line 12), when 'value == "Status"' is true

The function evaluation requires all threads to run.

Here's what the Threads window looks like:

Debugger Threads window

Anyone seen this before, or have any ideas what might be causing the debugger to baulk at this seemingly-simple case? Might it have something to do with the sleeping thread?

This links can be useful: http://msdn.microsoft.com/en-us/library/z4ecfxd9.aspx , http://blogs.msdn.com/b/greggm/archive/2005/11/18/494648.aspx — Petr Abdulin, Dec 15 '11 at 03:37
In my efforts to devise a workaround, I've found that it's *at least sometimes* possible to simply disable the breakpoint, run (`F5`) and immediately re-enable the breakpoint. I'd hazard a guess that the threading message isn't the red herring I had assumed it to be, although the actual cause still eludes me... Of course, the fact that the debugger needs any thread other than the current one to be active in order to evaluate a parameter value makes equally little sense to me. That said, I've never written a debugger :) — Tullo_x86, Dec 20 '11 at 23:21
@PetrAbdulin Good links, but I'm still at a loss as to why evaluating `value` (which is a parameter, which I would certainly hope isn't a func eval) and equating it to a string literal would do anything that requires another thread — Tullo_x86, Dec 21 '11 at 00:21
I guess it's a bug in debugger :) Maybe MSFT VS 2010 debugger team knows this and punted this for next release :P — Ankush, Aug 03 '12 at 19:11
I can't reproduce this based on the code that you've provided. — Justin Skiles, Aug 21 '12 at 19:52

score 1 · Accepted Answer · edited May 15 '14 at 15:03

1

I eventually devised a workaround:

public virtual string Name
{
    get
    {
        return _name;
    }
    set
    {
        if (value == "Status")
            DoSomeNoOp(); // Breakpoint here, or Debug.Fail() inside your no-op

        _name = value;
    }
}

edited May 15 '14 at 15:03

Peter Mortensen

30,738
21
105
131

answered Aug 23 '12 at 01:23

Tullo_x86

2,573
25
27

score 1 · Answer 2 · edited May 15 '14 at 15:02

1

I once had this problem when I encountered a situation when it goes out of the execution of the base thread. A bit more information on the flow of your application will help. It seems to me like a race condition.

edited May 15 '14 at 15:02

Peter Mortensen

30,738
21
105
131

answered Dec 18 '11 at 00:42

King

1,170
2
16
33

score 0 · Answer 3 · edited May 15 '14 at 15:03

0

I don't think it knows what value is. Try to put the breakpoint on the closing } and use _name in the condition.

edited May 15 '14 at 15:03

Peter Mortensen

30,738
21
105
131

answered Aug 22 '12 at 06:37

Johan

8,068
1
33
46

`value` isn't the problem; I've used that symbol in other conditions and it has worked fine. – Tullo_x86 Aug 23 '12 at 01:15

Why does Visual Studio fail to set a conditional breakpoint on this simple C# property?

3 Answers3