Hi, thanks for posting.

NCrunch follows the logic below with its workspaces:
1. A change has been made to a project, so the project must be rebuilt
2. NCrunch launches a Build Task. The build task attempts to secure a workspace to build the project
3. If an available workspace exists that isn't used by any current test, analysis or build task, NCrunch will use it
4. If no workspace exists or if they're all being used by something, NCrunch will create a new one

Because workspaces are fairly expensive to build, NCrunch won't clean them up during a session. Once a workspace has been created, it will exist until the session ends (caused by the engine shutting down and/or the solution being closed).

This means that if you're operating in a situation with a high level of concurrency and a large number of long-running tests, there's the possibility of many workspaces being created for projects that are heavily worked on. Picture a situation where you have 20 task runners, each running a different version of your source code spread across existing workspaces. If you're making rapid changes, each could potentially have their own workspace.

From an outside perspective, this can look crazy, but it does make sense. When a workspace is used, logically we cannot run a build in it (due to process file locks). This means that we'd either need to wait for resources (thereby hanging up the engine) or create a new workspace. For performance reasons, we do not do the former, only the latter.

Yes. The number of workspaces will be greatly affected by the number of execution threads and pooled processes you're running. If you have a large number of threads, it will take longer to reach the 'peak' workspace point for each project. The theoretical limit of workspaces can actually be very high if you have a large number of projects in your solution, but ordinarily change patterns will cause it to peak much lower.



NCrunch should always clean up the workspaces between sessions. There are two mechanisms to do this:

1. Workspaces should be cleaned up during a 'clean' exit of the engine. Not all exits are guaranteed to be clean, however.
2. So to compensate, when the engine starts, it will conduct a scan for orphaned workspaces and remove them.

With the current instability in the eco-system, I don't think I've ever had a session last as long as 3 days. If keeping the workspaces under control is important (i.e. when using a RAM disk), I'd suggest just resetting your NCrunch engine every so often to recycle your session and cause the workspaces to be cleaned up.

Avoid touching the workspaces while you have an NCrunch session in progress. This can cause the engine to become desynchronised with the workspace state and you'll likely end up with intermittent build errors.