Debugging Async Tests - variable "does not exist in the current context"

Whenever I try to view variable information in my tests whenever I try to use watches / immediate window / hover over objects I get "The name 'myVar' does not exist in the current context" when using the ncrunch runner, but works fine if I use MSTest directly.

The tests pass / fail correctly when they run, I'm just not able to debug them when run through ncrunch.

Is there some setting I need to change, or is this a bug?

Unfortunately, this is a bug.

Even more unfortunately, a solution to it has not yet been found.

The problem is caused by NCrunch's instrumentation/relocation conflicting with the 'magic' the Visual Studio debugger uses to look through compiler generated types, such as enumerators and await blocks. The physical structure of the code underlying these constructs is different to the code you are viewing in the debugger, and this causes VS's run-time resolution of the variables to fail.

I'm currently holding a hope that this can be resolved as part of a longer term plan, but currently no fix is available. Until a solution can be found, I recommend separating complexity from methods that use yield/await so that it's still possible to debug this code without NCrunch's build moving it away from the debugger.

Hey there,

I am having the same problem over and over again, too and switch back and forth inbetween the regular MS Test runner and NCrunch and to be quite honest, this is frustrating. Has there been any progress in this area or do I have to get used to to this?

Thanks,
-Jörg

(as a sidenote - it does work in other runners, e.g. R#'s test runner, too)

Sorry. No solution has yet been found for this problem.

Looks like no one has asked about this recently. Anyone know if this bug has been fixed within the past 6 months? I'm having the same problem now in VS 2013.

Hi,

A solution to this problem was released in NCrunch v2.11 earlier this year.

It seems I'm having this issue now, with VS 2015 and NCrunch 3.5.0.1. I have a yield method in the SUT, and it gets called and ToList()'d in the test, and the test asserts that the resulting List<> contains items (and the test passes during debug). Yet the debugger can't see the List<> variable, same error as OP two years ago.

Ah! Apologies, I missed that the OP was talking about async. I'm not doing any async here, just a yield method. But that seemed to be flagged as a cause in the first reply, so this thread caught my eye.

I do have resharper's test runner enabled, not sure if that causes problems under the hood. (That runner handles debugging the value of my variable fine btw.)

Hi, this could be a problem with the debug metadata.

Are you able to reproduce this in a code sample you can share with me?

Remco wrote:Hi, this could be a problem with the debug metadata.

Are you able to reproduce this in a code sample you can share with me?

Hi, thanks for following up with me. The project where I encountered the bug is a large solution with many interdependencies. I created a new project and tried to reproduce the bug there but so far I haven't been able to. I must be leaving out a critical element in my simplified repro project, as it does happen consistently in the orginial place where I encountered it. I'll keep working on that but it will be a few days before I have more time. Is there an NCrunch log file generated that could be of help?

Grendil wrote:
Hi, thanks for following up with me. The project where I encountered the bug is a large solution with many interdependencies. I created a new project and tried to reproduce the bug there but so far I haven't been able to. I must be leaving out a critical element in my simplified repro project, as it does happen consistently in the orginial place where I encountered it. I'll keep working on that but it will be a few days before I have more time. Is there an NCrunch log file generated that could be of help?

Because the log files don't contain any of your code, unfortunately they won't tell us much here. My expectation is that the problem is triggered by the code structure of the method you are trying to debug, so I would hope that you wouldn't need to arrange many project dependencies for this. Variable names are also of significant importance in debug metadata.