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

Notification

Icon
Error

Excessive shadow copies of solution assemblies
CourtJesterBob
#1 Posted : Monday, July 2, 2012 2:43:57 PM(UTC)
Rank: Member

Groups: Registered
Joined: 7/2/2012(UTC)
Posts: 13
Location: Beachwood, OH

We have been using nCrunch for a few months now, starting back with VS11 and now with RC2012 and just last Friday we noticed that nCrunch is copying all the .dll, .pdb, and .xml files, essentially all of the output from all of our projects in the assembly into many of the projects in my solution as well is into the IDE folder (C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE in my case).

This causes and isue with the ide not debugging the correct dll's as it will look for dll's in the IDE folder first and use the ones it finds there. So, if those are out of date, then you get irregular results.

Is this normal or is this a bug? Is there any way to control how/where nCrunch shadow copies the assemblies?

Bob
Remco
#2 Posted : Tuesday, July 3, 2012 9:04:11 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Bob,

Thanks for posting! This is definitely not normal behaviour. There have been reports of an intermittent issue that can result in DLLs being somehow built or copied to the root directory of a solution or project directories underneath it, but this is the first time I've heard it landing in the IDE directory.

Does the problem occur consistently for you? I.e. if you clear out the DLLs then reset NCrunch, do they reappear under the IDE directory?
CourtJesterBob
#3 Posted : Friday, July 6, 2012 1:44:24 PM(UTC)
Rank: Member

Groups: Registered
Joined: 7/2/2012(UTC)
Posts: 13
Location: Beachwood, OH

So, we have done some more investigation and here is what we have found.

First, we turned off NCrunch for a few days and none of our three team members had any issues.

Next, we turned NCrunch back on and monitored it. It finally happened again to one of our developers yesterday and he remembered exactly what he had done and this morning we did some small testing to try to isolate the issue.

Some background. We are using VS2012 with NCrunch 1.40.0.23b. We are also using MStest tests.

It seems that if you use VS2012 to run all tests "TEST...Run...All tests." while NCrunch is enabled, it will result in all of the output from all of the projects in the solution being copied to the IDE folder. If NCrunch is disabled and you run all tests, no file are copied.

So, I am not sure if it is VS2012 or NCrunch that is having an issue, but we noticed that both are trying to build the solution at the same time and run the tests at the same time.

Bob
Remco
#4 Posted : Monday, July 9, 2012 2:16:03 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Bob,

Nice analysis! I'll need to look deeper into this issue to find out how NCrunch is wrecking havoc with MSTest. My gut tells me this will be quite complicated to fix, so I'm afraid it may need to be included in a future release of NCrunch (or VS??).

I can suggest a possible workaround though. If the files are always being copied to the same place in the IDE folder, you may be able to introduce a rather nasty pre/post build event in one of your projects that routinely deletes them where they exist. If the timing of the build event is correct, it should mitigate the debugging issues.

Thanks again for reporting this issue. I can see it took considerable time to properly identify and I really appreciate the effort of your team.


Cheers,

Remco
Remco
#5 Posted : Monday, August 13, 2012 4:27:07 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,968

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi Bob,

I managed to look into this problem in a bit more detail and confirmed that it seems to be a concurrency issue with MSBuild.

As the issue is very inconsistent (and can only be intermittently reproduced), I haven't yet been able to identify the specific component in the build process that is responsible for it.

However, I've introduced some structural changes in NCrunch 1.41b (just released) which I hope will greatly reduce the chance of this happening. NCrunch should now automatically 'pause' processing while Visual Studio is performing a foreground build, which I hope should resolve the race condition experienced in your particular situation.

Give it a try and let me know how it goes.


Cheers,

Remco
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.040 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download