For NCrunch to be able to do its work without impacting other activities on the same machine, it needs to be able to set up temporary workspaces where it can perform its tasks in isolation.
The path for these workspaces will default to your User\AppData\NCrunch directory, but you can also control this via the workspace base path configuration setting. If you are working on a machine with a large amount of memory space, it could be a huge advantage to have your workspaces stored on a virtualised RAM disk to reduce the whirring of the hard drive.
When creating a workspace, NCrunch will automatically identify and copy all relevant project files to the workspace and arrange them using a directory structure that is (through relative paths) identical to the space from which they were taken. NCrunch will physically separate the project from its parent solution in order to build and test it independently. For this separation to be performed cleanly, NCrunch needs to be aware of all of the references from the workspaced project to any other projects within the solution.
If projects contain 'implicit' references to other files within the solution that NCrunch isn't able to automatically identify (for example, if tests in the project try to make use of a relative reference to files in a completely different project), the behaviour inside the workspace may not be the same as it would be in your original solution location. It's important that you let NCrunch know of all the files that a project needs in order to build and run its tests. You can do this by either ensuring all dependencies are included in the project file or by using the Additional files to include configuration setting.
Because each NCrunch workspace represents a project that has been fully extracted from its parent solution, projects being processed by NCrunch must be atomic and extractable.
NCrunch will often build several copies of the same workspace to give itself space for parallel builds and test execution. The workspaces are carefully versioned and regularly updated from your source code while you change it, to ensure no strange build or test behaviour. There is physical separation in the naming of workspace directories to prevent different instances of Visual Studio from interfering with each other if they are each using NCrunch simultaneously. Workspaces will regularly be cleaned up when they are not in use, and NCrunch will also take care to delete orphaned workspaces that may be left behind by improperly terminated instances of Visual Studio.
If you are working with a solution that requires a large amount of disk space (for example, if you have large database backups or spreadsheets included in your project files), you may find that your first few build tasks will take some time after NCrunch is first enabled. This is because of the overhead of copying large files across the hard drive while setting up workspaces. Once enough workspaces have been created for NCrunch to work efficiently, the processing time of build tasks should drop noticeably.