Hi Yang -

This is something I did look at earlier, as it would reduce the amount of file copying going on.

Unfortunately, it wouldn't solve all the isolation issues that come with the need to separate projects from their base solution. The big reason NCrunch copies these files is because of file locking issues - DLL files are locked by any application domain that makes use of them, which means they cannot be modified or replaced while tests are in progress or their host processes are still running.

There is actually a project-level configuration setting that you might find useful - Include static references in workspace. When turned off, NCrunch will avoid copying DLL files into the workspace and will simply reference them from your foreground solution. As described, a side-effect of doing this is that you'll find you are unable to update any of these DLLs while the NCrunch engine is enabled - but this should greatly reduce disk consumption on your ram disk.


Cheers,

Remco

#1 - Definitely.

#2 - Sort of. In the current architecture, NCrunch can run multiple sets of tests concurrently using the same workspace, which technically does mean that tests can already be sharing the same set of DLLs. Extensive real-world testing has shown to be largely safe to do. The problems around concurrency generally occur more around build steps. Build steps have the potential to do some particularly crazy things with files - everything from copying them around to manipulating their physical structure (i.e. PostSharp). NCrunch is able to fire off a new build for a project while this project is already being used for testing tasks being run in parallel - this wouldn't be safe to do without building a completely new workspace with a new set of files.

Having a single file shared between multiple workspaces also introduces new complexities - such as finding a safe time to update the file if it is changed in the foreground solution. Files can only be updated when all test processes using them have been terminated, so by isolating the use of files to individual workspaces, NCrunch always has the flexibility to build a completely new workspace to deal with any concurrency issues. Where resources are shared between workspaces, NCrunch then needs to wait for all shared use of these resources to expire before it can update the resources ... this may include waiting for some very big long tests to finish their execution.

I hope this makes sense :) File locking issues are easily one of the largest constraints on the engine and were a huge source of problems in early releases of the product. It's taken quite a bit of trial and error to find a way to work them out, but the current model works fairly well as long as people don't introduce absolute file path references in their solutions.