I'm experiencing an issue where the code coverage indicators are not aligned with the statements they cover. Has anyone else experienced this and know of a fix? I'm rather suspecting it might be related to CodeLens as that screws with the line spacing...

Thanks Steve. The report confirms that this isn't the result of a tragic and obvious malfunction, which is somewhat disappointing as it means this will be very hard to find.

I'll try to share with you the information I have on this problem in the hope that it might help you to narrow down what is causing it on your side.

- The problem happens as a result of an internal desync between the actual code positions and NCrunch's code coverage index- It is not a visual/UI based issue, which means that this is happening in the engine itself- It is not likely to be the downstream result of a separate issue (no exceptions appearing in the logs)- It's been at least a couple of years since we last had a known and reported issue in this area- The code responsible hasn't been touched for a year or more- This leads me to believe there is something unique about your solution or environment that is surfacing the issue- Previously, I have observed this issue appearing with tiny projects that have an unexpectedly fast build time. This was due to MSBuild's filestamp-checking cache system preventing the compiler from working correctly on rapidly repeated builds

Are you running any other 3rd party tools inside your IDE? Is there a particular project that seems to be singled out by this problem? Are you using distributed processing?

I'm running the latest version of Visual Studio and the only plugins other than NCrunch are ReSharper (with ReSpeller) and PowerMode.It is quite a small project - it's an AWS Lambda, so essetially just one function with perhaps dependencies on about 3 other classes and the AWS SDK.

I think that this problem may be related to an optimisation in MSBuild, where it doesn't update files unless they have a timestamp mismatched with the file being updated. I've seen this happen before when using high-end hardware on tiny projects with older versions of MSBuild (i.e. 2008, 2010), because the system runs the build so quickly that two different builds executed in sequence don't have enough of a gap for the timestamp to be separated, so the files don't get copied and the source code falls out of sync with the binaries.

This is all theory at this stage, because such a situation is so hard to reproduce that there isn't likely to be a way that I can confirm that it's happening for you. To be honest, it's been years since I've seen it happen.

However, if it IS the problem, then likely it will go away on it's own as you continue to add code to your project. All you need is the tiniest increase in your build time, and you'll never see it again.

There is a known issue where CodeLens changes the vertical size of some lines of code (notably the first line of constructors). This causes the NCrunch markers to look a bit out of place on these lines, as they are aligned with the top of the line rather than the bottom.

I've had a bit of a brainwave today and I think I may have found a way to fix this by aligning the markers to the bottom of the line instead. I'd like to dogfood this for a while before releasing it in case it breaks VS somehow, but I'm hoping that you'll see this out with the next version of NCrunch.

I think that this problem may be related to an optimisation in MSBuild, where it doesn't update files unless they have a timestamp mismatched with the file being updated. I've seen this happen before when using high-end hardware on tiny projects with older versions of MSBuild (i.e. 2008, 2010), because the system runs the build so quickly that two different builds executed in sequence don't have enough of a gap for the timestamp to be separated, so the files don't get copied and the source code falls out of sync with the binaries.

This is all theory at this stage, because such a situation is so hard to reproduce that there isn't likely to be a way that I can confirm that it's happening for you. To be honest, it's been years since I've seen it happen.

However, if it IS the problem, then likely it will go away on it's own as you continue to add code to your project. All you need is the tiniest increase in your build time, and you'll never see it again.

I also note that my solution, and in particular the project that this test is covering, is rather large so I suspect it's not the timing issue here.

I realise that this is a hard issue to solve for. More than anything just letting you know that there looks like a few of us out here having the issue. It's a bit of a shame as I'm trying to convince my client to purchase NCrunch for the dev team and this issue doesn't help my case. :( Overall though, I've been using NCrunch for years and think it's an awesome tool! #welldone

Groups: Registered
Joined: 11/28/2018(UTC)Posts: 3Location: United States of America

Was thanked: 1 time(s) in 1 post(s)

I'm seeing the same thing as Remco with the latest build in VS2017 using CodeLens. I noted that the NCrunch markers are lined up properly initially, then the CodeLens information pushes the lines downward. Unfortunately, the NCrunch markers don't follow the lines.

Is it possible to maybe offer a way to refresh the markers on the screen without closing the file? That might get it to line up properly.

I'm seeing the same thing as Remco with the latest build in VS2017 using CodeLens. I noted that the NCrunch markers are lined up properly initially, then the CodeLens information pushes the lines downward. Unfortunately, the NCrunch markers don't follow the lines.

Is it possible to maybe offer a way to refresh the markers on the screen without closing the file? That might get it to line up properly.

I'm having trouble reproducing this issue. The Codelens 'lines' are usually represented in the IDE as just being a vertical extension to an existing code line (i.e. the code line is just made bigger), so I'm concerned about how this seems to be happening on some systems.

Does this happen consistently for you? Does disabling codelens resolve it? Are you running any other 3rd party VS extensions that might affect VS code rendering?

Technically, scrolling the code up and down should cause the markers to be re-rendered, but this won't rebuild the marker gutter container. Closing and reopening the file is the only way to completely reset things.

Am I correct in my understanding that this is an intermittent issue for you?

Groups: Registered
Joined: 11/28/2018(UTC)Posts: 3Location: United States of America

Was thanked: 1 time(s) in 1 post(s)

Remco;12860 wrote:

I'm having trouble reproducing this issue. The Codelens 'lines' are usually represented in the IDE as just being a vertical extension to an existing code line (i.e. the code line is just made bigger), so I'm concerned about how this seems to be happening on some systems.

Does this happen consistently for you? Does disabling codelens resolve it? Are you running any other 3rd party VS extensions that might affect VS code rendering?

Technically, scrolling the code up and down should cause the markers to be re-rendered, but this won't rebuild the marker gutter container. Closing and reopening the file is the only way to completely reset things.

Am I correct in my understanding that this is an intermittent issue for you?

It happens consistently on certain files (I didn't find any that had issues that weren't repeatable), however you're absolutely right that scrolling seemed to fix the alignment issue. I also tried disabling CodeLens, and it rendered without issue. Upon re-enabling CodeLens, the issue returned.

Great to know simply scrolling with fix the issue. I will update if I find another instance where this doesn't fix things.

It happens consistently on certain files (I didn't find any that had issues that weren't repeatable), however you're absolutely right that scrolling seemed to fix the alignment issue. I also tried disabling CodeLens, and it rendered without issue. Upon re-enabling CodeLens, the issue returned.

Great to know simply scrolling with fix the issue. I will update if I find another instance where this doesn't fix things.

If you have any luck in identifying what is special about these files and why it only happens for them, I'd really like to know. If I can reproduce the issue, maybe I can fix it for good :)

It's suspicious the way this has suddenly come up with a VS update. I wonder if it might be an internal issue inside VS itself. In which case it may even disappear on its own.

You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.