This is by design. It is due to the mechanics through which the await construction is implemented.
When the .NET runtime hits the await, it actually runs the thread through to completion and sets up a continuation pointed back at the await. When the awaited call completes, a new thread picks up the code from the point where the calling method was interrupted.
These mechanics happen above the level at which NCrunch operates, so the coverage tracking is completely unaware of them.
'await' was implemented by Microsoft in the same manner as 'yield'; all the complexity is in the compiler rather than in the runtime. This means that if you look at the MSIL generated from class using await, you'll see an extensive set of compiler generated methods and classes that have little to do with your own code and much more to do with the piping around await itself. It is theoretically possible for NCrunch to be upgraded to identify the 'await' by closely inspecting and analysing this structure, but this will come at a serious cost in terms of lost performance and significant complexity - it likely wouldn't be worth it.
I understand the complexity of supporting this but IMHO the hotspot indicators in NCrunch is one of those "killer features" that stands out. Given that asynchronous programming is getting more mainstream (even Entity Framework supports it :)) maybe this is a feature request that will raise in popularity with time.
I understand the complexity of supporting this but IMHO the hotspot indicators in NCrunch is one of those "killer features" that stands out. Given that asynchronous programming is getting more mainstream (even Entity Framework supports it :)) maybe this is a feature request that will raise in popularity with time.
But future will tell I guess :).
Fair enough :) If you'd like to drop it on uservoice as a feature request, it may become popular enough to be worth investigating more.