Hi Patrick,
Thanks for posting!
The workspaces are handled very differently on servers to the snapshots (which can be size limited). This is because NCrunch tends to create and remove workspaces transiently as required, while the snapshots are considered to be long term storage. Workspaces on the server are handled in the same way as they are in the NCrunch VS client.
It's worth being aware that there is a limit to the number of workspaces NCrunch will create - it doesn't just keep going up and up, although disk consumption may vary greatly depending on your solution. Unless you are actively running out of disk space on the server, you may not need to take action here.
The only way to influence the number of workspaces is indirectly through configuration settings, particularly the 'Max number of processing threads' and 'Process pool size' settings. Setting these options to lower values will reduce the number of workspaces NCrunch requires at any one time.
Unfortunately there is no feasible way for NCrunch to limit the number of workspaces it creates. The problem behind this could in many ways be compared to a process trying to limit its overall memory consumption. NCrunch would not be able to avoid creating new workspaces without greatly inhibiting its own operations at a level that would make the distributed processing fairly useless. If you're having problems with disk space running out on the server, there are several options for resolving this:
1. Adjust the 'Max number of processing threads' and 'Process pool size' to lower values so that NCrunch needs less workspaces
2. Look at ways of reducing the disk consumption of each workspace. Check for large files that are being included in the project file or 'Additional files to include' setting that aren't actually needed by NCrunch. Files that are included using 'Additional files to include' at solution level are shared between ALL projects in the solution and can greatly increase disk consumption, so make sure you have nothing included here unless it's absolutely needed.
3. If the node is part of a more extensive grid shared between several people, consider splitting the grid so that each node is shared between less people
4. Increase available disk space on the grid node (I know this is probably what you are trying to avoid, but sometimes if you're running in a VM, it's just the easiest option)
