Hi,

Thanks for sharing this problem.

This is a known issue. It's been around for a very long time, and though it's well understood what causes it and even what can be done to fix it, at the moment the better option seems to be not to fix it. I'll try to explain why ...

When NCrunch instruments your assembly for code coverage, it needs to reconstruct the PDB file for this assembly from scratch. This is because all the metadata in the PDB needs to be kept in alignment with the instrumented assembly. Presently, this can only be done using Microsoft's unmanaged symbol writer system that is built into the O/S. This component is very old and it does have some limitations; particularly, it doesn't perform as well as I would like it to.

Inside the PDB, each method (with its local variables) is represented as a series of scopes (basically the {} in C#). Each scope has its own independent variable declarations, which is what allows languages like C# to have the behaviour you've shown above, with two different variables sharing the same name.

The problem is that the MS unmanaged symbol writer can only be fed instructions one scope at a time. This action is fairly expensive (in relative terms), so it's in our interests to use it as little as possible. For this reason, NCrunch actually 'flattens' the scopes for each method into a single scope that contains all instructions. The net effect of this is greatly improved performance at the cost of some strange debug behaviour when examining variables that share the same name.

So basically, it wouldn't be possible to fix this without a noticeable reduction in instrumentation performance .. which means more time waiting for builds to run.

There may be other models that can solve this problem at the cost of greater complexity, and there are also some opportunities on the horizon. For example, the unmanaged symbol writer is now open source, so it's finally possible for us to write our own symbol writers that perform much better. Unfortunately this all involves an investment of time and effort to solve a problem that is a relatively low priority compared to many of the newer issues related to other changes into the ecosystem (i.e. .NET Core, VS2017, CPS, etc). So I don't think we'll see a solution to this in the near future.