Hi, thanks for posting.

The 'Copy referenced assemblies to workspace' setting does have a significant impact on performance, as this requires much more to be rebuilt when changes are made.

I'm going to guess that the root problem here is the umbraco configuration files not being in the same directory as the test project DLL when the tests are run. Most likely umbraco is always searching for these files in the AppDomain basedirectory or the current directory.

The key underlying issue here is that because the files belong to one project (your application DLL) but are referenced as part of another project (your test DLL), both of these projects need to be rebuilt with full references copied in order for the files to land in the right place.

If you have access to the code responsible for finding these files, it may be sensible to change it so that it searches in the directory of the DLL they are associated with, rather than the test assembly.

Another option could be to either duplicate these files into your test project (or create a cut-down version of them that will work for testing), then make sure these are marked as copy local.

A more complex but effective solution is to implement setup code inside your test that will seek out the files and copy them into the test project's working directory as part of the test. The NCrunch.Framework library has a method that allows you to find the build output directories of projects being referenced by the test project - see http://www.ncrunch.net/documentation/reference_runtime-framework_environment-class for more information on this one. This will require you to implement NCrunch-specific code inside your test project, though you can easily cover yourself using '#if NCRUNCH' directives so the tests can still work with other runners.

NCrunch uses an optimised build to try and improve feedback times. Turning on the 'Copy referenced assemblies to workspace' setting disables these optimisations and makes the build behaviour closer to what you would experience when building your project in VS. I recommend having a read of this documentation page - http://www.ncrunch.net/documentation/considerations-and-constraints_assembly-colocation-assumptions .. it explains the behaviour in a bit more detail and gives some more information on how to work around such problems.

In your case, the problem is caused by co-location assumptions of resource files (the .config files) rather than DLLs .. but the principle is much the same. When the 'Copy referenced assemblies to workspace' setting is disabled, NCrunch will suppress the msbuild steps used to copy referenced files into the build output directory of referencing assemblies. This allows it to override the assembly loading behaviour of the CLR at runtime and wire together the test application domain artificially, thereby allowing it to build projects selectively instead of through big rebuild actions. It's always possible to work around NCrunch's behaviour, but sometimes it takes a bit more understanding of what is happening and requires some more effort. Many people are OK with just enabling 'Copy referenced assemblies to workspace' as this gives a quick (if poorly performing) solution.