workspaces taking a lot of disc space

I've moved my 'Workspace base path' to ramdisc (currently 512 MB) and NCrunch can 'eat' this space in under one minute of code editing:)

My tested assembly has many dependencies on my own components and 3rd party component which has dependecies to many C++ dll's. My assemblies are copied by ncrunch to <workspace>\_ncrunchreferences (48MB) and <workspace>\bin (is this duplication neccesary?). I'm using 'Additional files to include' to copy some of the 3rd party components to <workspace>\bin (about 40MB) and my tests works fine, but at this point <workspace> takes 136 MB.

Of course, I can switch back to HDD, or add more Ram to RamDisc, but maybe there is some other way to configure my solution and ncrunch to be less disc space hungry? Maybe I'm doing something wrong?

I had a 4GB ramdisk, and it kept getting filled up. I would have to disable/reenabe NCrunch (or restart the solution) to get it to clean up.

NCrunch will create as many workspaces as it needs to meet the engine's requirements for parallel build/execution. This means that the number of workspaces you see during a session will be fairly well in proportion with the global performance settings, 'Max number of processing threads' and 'Process pool size'. If you set these values lower, you should see less workspaces appear as the engine will be doing less work concurrently and consuming less resources. However, this will probably not work too well with your performance tuning goals, as turning these options down too far will likely create bigger performance issues than would otherwise be solved by introducing the RAM drive.

The duplication of workspaces is necessary because at any point in time, NCrunch can be running uninterruptable tests against any version of your source code. Let's just say you have a big integration test that takes 20 minutes to run and relies on a number of resource files inside your codebase... if you were to change several of these resource files while the test is already executing, it's important that the executing test can continue to work consistently and without consideration to the new changes.

NCrunch 1.37b (and below) has a known issue around read-only files, where if they exist in your solution, NCrunch will often fail to properly clean up workspaces that contain them. This only applies to final clean up (i.e. when NCrunch is disabled or the IDE is closed), but it can cause the number of workspaces to grow over time. This is particularly an issue if you're using any kind of VCS software that flags files as read-only during its normal operation.

For anyone interested, the issue with cleaning up workspaces containing read-only files has been fixed in the NCrunch version just released (1.38b).