Do I need to switch to v2 for better await async support? I recently came across the following - when I tried to look at "words" during an NCrunch Debug I could not.
[img](- BROKEN LINK -)[/img]
Remco NCrunch Developer
#5022
08 Jan 2014 04:46 UTC
Hi,
At the moment, NCrunch has no way of handling such a debug evaluation.
This is because keywords such as 'await' involve the creation of whole new structures of code at a metadata level. The instrumentation that NCrunch performs on the assembly skews with the 'magic' performed by Visual Studio to allow it to see through these structures, preventing the debugger from working correctly.
The 'yield' statement is also affected by this problem.
I'm sorry to say that I haven't yet found a way to make Visual Studio work with this. This issue affects both V1 and V2.
Cheers,
Remco
At the moment, NCrunch has no way of handling such a debug evaluation.
This is because keywords such as 'await' involve the creation of whole new structures of code at a metadata level. The instrumentation that NCrunch performs on the assembly skews with the 'magic' performed by Visual Studio to allow it to see through these structures, preventing the debugger from working correctly.
The 'yield' statement is also affected by this problem.
I'm sorry to say that I haven't yet found a way to make Visual Studio work with this. This issue affects both V1 and V2.
Cheers,
Remco
Does it matter if I use another testing method? Like Microsoft's vs nunit. This is really aggravating.
Remco NCrunch Developer
#5084
17 Jan 2014 22:41 UTC
Sadly not. All test frameworks work with the same compiler and instrumentation, so they all have the same problem.
The only way I'm aware of that can reduce the impact of this is if you try to avoid placing logic within methods that make use of await/yield. For example, moving the assertions above to another method, so that the local variable becomes a method parameter. Sorry, I know it's not ideal. There's a big technical constraint here that I haven't yet found a way around.
The only way I'm aware of that can reduce the impact of this is if you try to avoid placing logic within methods that make use of await/yield. For example, moving the assertions above to another method, so that the local variable becomes a method parameter. Sorry, I know it's not ideal. There's a big technical constraint here that I haven't yet found a way around.
Hi Remco,
Is it possible to have another Debug unit test option in NCrunch, such as, "Debug without NCrunch Instrumentation" and/or "Break into first covering test without instrumentation" that would just launch VS into a debugging session without the instrumentation? With those new options available I'd leave instrumentation on almost all the time, except when I need to debug async/await methods. Unfortunately, for NCrunch use anyway, I seem to find myself writing more async/await methods these days!
As it stands today when I need to debug async/await I have to use Resharper's test runner to launch a debug session. I love 'Break into first covering test', especially with the keyboard shortcut, and use it all the time and its kind of a pain to then have to drop a breakpoint and then find the unit test so that I can launch Resharper's test runner.
Just a thought, let me know what you think.
Thanks,
Paul
Is it possible to have another Debug unit test option in NCrunch, such as, "Debug without NCrunch Instrumentation" and/or "Break into first covering test without instrumentation" that would just launch VS into a debugging session without the instrumentation? With those new options available I'd leave instrumentation on almost all the time, except when I need to debug async/await methods. Unfortunately, for NCrunch use anyway, I seem to find myself writing more async/await methods these days!
As it stands today when I need to debug async/await I have to use Resharper's test runner to launch a debug session. I love 'Break into first covering test', especially with the keyboard shortcut, and use it all the time and its kind of a pain to then have to drop a breakpoint and then find the unit test so that I can launch Resharper's test runner.
Just a thought, let me know what you think.
Thanks,
Paul
Remco NCrunch Developer
#5589
25 Mar 2014 21:44 UTC
Hi Paul,
My first preference would be to fix the debugging so that it would work with the instrumentation :) Of course, the technical constraints are such that I don't see this happening any time soon. Your feature makes good sense. Do you want to put some votes towards it at https://ncrunch.uservoice.com?
My first preference would be to fix the debugging so that it would work with the instrumentation :) Of course, the technical constraints are such that I don't see this happening any time soon. Your feature makes good sense. Do you want to put some votes towards it at https://ncrunch.uservoice.com?
Hi Remco,
Thanks for the reply. I added the suggestion to the NCrunch uservoice site.
Thanks,
Paul
Thanks for the reply. I added the suggestion to the NCrunch uservoice site.
Thanks,
Paul
Post a reply
Log in to reply.