Hi,
To build the projects in my solution requires some libs to be copied locally to the project, which I have done using "Additional files to include". Unfortunately these libs are approx 12GB and they are being copied over and over until the machine eventually runs out of space. Is there a way to configure NCrunch somehow to minimise the copying? Perhaps limit to a single workspace at one time? Also it should avoid copying those files again every time it builds as it takes a long time to do that!
Many thanks
Jeremy
Remco NCrunch Developer
#5409
26 Feb 2014 12:55 UTC
Hi Jeremy, thanks for posting!
You have a couple of options on how you can solve this issue.
The first one is to reduce the number of workspaces by adjusting the engine's configuration. If you set the max number of processing threads setting to 1, and set the max test runners to pool setting to something low (perhaps even 0), NCrunch will perform less tasks concurrently and require less workspaces to be built. This is probably the least preferable approach in my view, as the engine will work much slower because of this.
The second one is to reference the libraries from the original (foreground) solution. Normally this isn't recommended with NCrunch, as it breaks workspace isolation, but when done carefully it can be safe. My assumption is that at least a large part of the 12GB does not change regularly and may even be read-only. This means you're unlikely to have issues with file locks or resource conflicts. If you adjust your code to reference these files using the methods on the NCrunch environment class, you can avoid copying them entirely and everything should run very quickly. If need be, introducing an override specific to NCrunch in your code may be of use with this approach.
I hope this helps.
Cheers,
Remco
You have a couple of options on how you can solve this issue.
The first one is to reduce the number of workspaces by adjusting the engine's configuration. If you set the max number of processing threads setting to 1, and set the max test runners to pool setting to something low (perhaps even 0), NCrunch will perform less tasks concurrently and require less workspaces to be built. This is probably the least preferable approach in my view, as the engine will work much slower because of this.
The second one is to reference the libraries from the original (foreground) solution. Normally this isn't recommended with NCrunch, as it breaks workspace isolation, but when done carefully it can be safe. My assumption is that at least a large part of the 12GB does not change regularly and may even be read-only. This means you're unlikely to have issues with file locks or resource conflicts. If you adjust your code to reference these files using the methods on the NCrunch environment class, you can avoid copying them entirely and everything should run very quickly. If need be, introducing an override specific to NCrunch in your code may be of use with this approach.
I hope this helps.
Cheers,
Remco
Hi Remco,
I think I prefer the second option because as you correctly assumed, these files are effectively read-only and change rarely.
Is there any way of referring back to the original SolutionDir rather than the NCrunch workspace one? If so, then I could set it up to reference the binaries rather than copying if $(NCrunch) == 1.
Thanks
Jeremy
I think I prefer the second option because as you correctly assumed, these files are effectively read-only and change rarely.
Is there any way of referring back to the original SolutionDir rather than the NCrunch workspace one? If so, then I could set it up to reference the binaries rather than copying if $(NCrunch) == 1.
Thanks
Jeremy
Remco NCrunch Developer
#5487
07 Mar 2014 10:35 UTC
Edited 07 Mar 2014 10:53 UTC
Post a reply
Log in to reply.