Good day!

I remember, when I've used NCrunch beta, where was an issue on debugging application executed from NCrunch made binaries - Immediate window somehow didn't recognize namespaces (for example System.Windows.Forms). It's still here in 1.42. Would it be resolved?

Hi,

The line "where was an issue on debugging application executed from NCrunch made binaries" grabbed my attention.

Although I don't understand the original posters comments completely, it does look like they are having a similar issue to ourselves.

It's not consistent, but we seem to get project assemblies copied to the root of our project, sometimes it also copies the assembly's xml file alongside it. It can range from a couple of assemblies to 10s.

We only tend to notice when we commit some code which is when Git lists any untracked files that can then contain some of our compiled assemblies (but in the root, not in our bin folders).

Remco, is that the side effect of your pdb manipulation? Or was that repy to something different entirely?

Thanks,

Simon

Remco,

Sorry for hijacking a thread then.

We are using Visual Studio Premium 2012, and the only things of note we use within it are Resharper 7.0.1 and Nuget 2.1.

I personally don't use any of the test runners in Resharper but a few of my colleagues do.

Any more information that might help you track down the issue I'd be glad to provide it.

Cheers,
Simon

On large commits it is quite easy to miss the assemblies and check them into to source control; so not serious, just irritating.

I have been using NCrunch for around 4 months now, and it has only just started happening - maybe the last week for me, and a few weeks earlier for some others.

We upgraded to VS2012 around 2 months ago and moved to the latest Resharper at the same time.

I've just upgraded to 1.45.0.28 and now the problem seems to manifest a bit more aggressively. Instead of a few dlls appearing throughout the project folder we now get up to hundreds in a short space of time.

@yanglee what version of the NuGet Package Manager extension are you using?

I've got 2.6.40627.9000 installed.

Something else to look out for is whether your NCrunch configuration has any dependencies on files derived from your local build process.

If you run a build and this triggers NCrunch to start working, then most likely you have an output from your foreground build that has been specified as an input for NCrunch through either a project file or the 'Additional files to include' configuration setting. Solutions with this problem have a much higher chance of the DLL copying issue appearing, because every time you run a foreground build, it will trigger NCrunch thus creating a situation where the builds can overlap.

It's worth checking to see if this is the case for your solution. The best way to resolve the issue is to track down the build output files being referenced by NCrunch and remove them from the project file(s) and 'Additional files to include' settings. You'll know when you've fixed it, as you'll be able to build your solution without NCrunch kicking off.

Thanks Yang. The update of Nuget packages involves changing files that NCrunch does reference, so this would have triggered NCrunch to kick off. I'm not completely sure if Nuget performs build logic during an update, but if so, this could explain a possible cross-build issue. Do you remember if the issue appeared multiple times since the package update, or only during the package update?