Hi, thanks for posting!

Unless there is something specific in your build process or test code that is intended to copy files to these two locations, then this behaviour is not by design.

There is a known issue with NCrunch where sometimes NCrunch builds can overlap with foreground builds in Visual Studio, causing these two processes to interfere with each other. This results in files occasionally being copied to the solution/project directories. The files can safely be deleted as they are not used by NCrunch.

If you experience this often, check that you don't have anything in your build that causes NCrunch to trigger. Sometimes people have NCrunch set to watch files that are derived from the foreground build (i.e. using the' Additional files to include' configuration setting), and when you run a build in Visual Studio, it causes these files to change, thus triggering NCrunch and creating a rare scenario where builds may overlap.

You can find more information about this problem at http://forum.ncrunch.net/yaf_postst242_DLLs-Copied-to-project-s--root-directory.aspx. Measures are being taken to reduce the chance of it happening, but it is a difficult problem to reproduce in environments where it can be resolved.


Cheers,

Remco

Hi Daniel -

Sorry, I don't think I explained this very well .. the files actually aren't supposed to be copied at all - they shouldn't even be in your commit list. There are things you can do to prevent this bug from showing. The link shown above contains a post giving step by step instructions you can use to find out which files Visual Studio is touching that is causing NCrunch to overlap its build with the Visual Studio one. If you can get rid of the overlap, you shouldn't see these files anymore.


Cheers,

Remco

Hi Daniel -

At the moment the reason for the file copying isn't clear. This appears to happen inconsistently in a small minority of environments, and there are so many variables involved that presently we haven't found a way to reproduce the issue in an environment where it can be fixed. My suspicion is that the issue is related to NCrunch's workings with MSBuild, as MSBuild is actually responsible for the copying of files. This means that at the moment, I'm afraid I can't offer you fixed version of NCrunch that will solve this problem. However, I can offer you steps to simplify your NCrunch configuration to remove the occurrence of the issue from your environment.

As mentioned earlier, the problem is caused by overlapping builds. This means that the best way to remove the problem is to prevent builds from overlapping in your environment. In the vast majority of cases, overlapping builds are caused by NCrunch being configured to watch files that are output from your foreground build. This creates a situation where you execute a build in Visual Studio, then NCrunch suddenly notices an update to your source code and starts building projects. Ideally, you want to be in a situation where running a build on your solution in VS will not trigger any state change from NCrunch.

If NCrunch is giving you warnings about references to files output from the build process - I recommend taking these warnings seriously. They can provide useful information about implicit behaviour within your build process. If you have no warnings showing, it is possible to use NCrunch's trace log to identify which file change is causing the engine to trigger in the following way:

1. Enable the 'log to output window' configuration setting in your global NCrunch config
2. Set the log verbosity to 'Medium'
3. Set the engine mode to run tests manually (to avoid noise)
4. Open the VS output window and choose 'NCrunch Diagnostic Output' in the dropdown list
5. Build one of the projects that you believe is causing NCrunch to trigger (using Visual Studio)
6. Watch for when NCrunch triggers, then look through the log for a 'ComponentMemberUpdatedEvent', or a 'ComponentAssemblyReferenceUpdatedEvent'. These events identify files that have been updated and will therefore trigger the engine to run a build.

It is highly desirable to be in a situation where you cannot cause NCrunch to trigger a build by executing a build in Visual Studio. While there are many solutions that work fine with NCrunch even though their builds trigger in this way, it's always the first thing that should be addressed when experiencing random problems like those described above.

Thanks Daniel, do let me know how you get on. Also, feel free to submit a bug report the next time you have this happen to you. I'm always looking for opportunities to pin this issue down so it can be isolated in a development environment, and the log file may yield some interesting clues as to why MSBuild is doing this.