Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Sometimes near Empty Autos and Locals Window when debugging a Test with NCrunch
Der-Albert.com
#1 Posted : Thursday, May 2, 2019 7:29:56 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 5/17/2011(UTC)
Posts: 171

Thanks: 8 times
Was thanked: 37 time(s) in 34 post(s)
Hi,

i have this since some months, when I debug a test with NCrunch, then the Autos and Locals Windows shows only this as exploreable (more or less).

Same test while Live Streaming.

with NCrunch https://www.youtube.com/watch?v=Hsl6Ps1LanY&feature=youtu.be&t=6018

and

with ReSharper https://www.youtube.com/watch?v=Hsl6Ps1LanY&feature=youtu.be&t=5945

As you can see, when started with ReSharper everything as expected. When Running with NCrunch the Debugging Session is useless.

I have this on 2019 and 2017, but was not able to reproduce this on purpose. But when it happens it is consitent on the part of the source code. I checked this on another machine
(my main work machine) and it happens also there. So here is the repository https://github.com/DerAlbertLive/FamilyCalendar.

PersonTests.cs as you can see in the Videos.

Best Regards

Albert
1 user thanked Der-Albert.com for this useful post.
michaelkroes on 5/2/2019(UTC)
Remco
#2 Posted : Thursday, May 2, 2019 11:03:07 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,722

Thanks: 744 times
Was thanked: 950 time(s) in 905 post(s)
Hi Albert,

Thanks for sharing this problem.

This is caused by a known issue in NCrunch's handling of PDB metadata. Recently, something has changed inside the platform that has made this problem more serious.

Unfortunately, it's not so easy to fix. NCrunch's PDB metadata is built on an aging library that was built long before a range of metadata extensions were implemented by MS. Our solution right now is to replace the library entirely with a targeted solution. I'm happy to say this has been progressing well but it will be a few weeks before we're able to publish builds with the new system in place.
1 user thanked Remco for this useful post.
Der-Albert.com on 5/5/2019(UTC)
Remco
#3 Posted : Monday, May 20, 2019 6:40:18 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,722

Thanks: 744 times
Was thanked: 950 time(s) in 905 post(s)
Der-Albert.com
#4 Posted : Monday, May 20, 2019 9:32:06 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 5/17/2011(UTC)
Posts: 171

Thanks: 8 times
Was thanked: 37 time(s) in 34 post(s)
I quick test with the Solution, it works now. but I have to simple work with NCrunch to see if that happens again. But this week is a short working week for me with much project management. But you can be sure that I will not be quiet about it if it happens again.

Btw. may this have also impact on the problem with async Task Test? I switched to WatchText for impact detection a long time ago, because NCrunch is sometimes not reliable to detect impact with CompareIL (there must an old thread about this here in the forum). But it was not really reproducible.
Remco
#5 Posted : Monday, May 20, 2019 9:42:41 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,722

Thanks: 744 times
Was thanked: 950 time(s) in 905 post(s)
I don't expect this will change anything around the impact detection, or anything that may be related to async/await.

The problem here was triggered by the following statement:
using Person = FamilyCalendar.Web.Models.Person;

This statement causes a small change in the way namespaces are declared in the PDB. We weren't handling this right, and since VS2015 apparently it can cause the debugger to fail to resolve locals. Others have reported this problem in the past but we could never pin it down because we didn't have the code to do it. Your repo changed that :) We've noticed the tooling seems to be doing type aliasing more often now so it's likely this is the reason many people are experiencing the issue more in the last few months.

While rewriting our instrumentation system I've discovered a few other areas where our old handling of PDBs hasn't been right, but it hasn't been practical to fix these issues because that whole area of code is going in the bin soon. I look forward to the day when we aren't plagued by these sorts of problems anymore.
Users browsing this topic
Guest
Forum Jump  
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.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.037 seconds.