Hi,
I've re-ignited my ncrunch thing, as you'll see from my rate of posts :),
I've setup the workspace path to a ram-drive (x:\ncrunch for me),
One of the things I'm finding weird, is then when I shutdown visual studio, the whole workspace gets delete
(i.e. x:\ncrunch\* is cleaned out), and when I restart visual studio the whole thing starts from scratch, which in my case take about 2-3 minutes for ncrunch to compile and test 70+ projects.
Is this normal? I don't seem to remember this back @ ncrunch v1 when I played with it a while back.
Can this be avoided?
Build/Test Issues
NCrunch does complete rebuild when opening a solution
Started by damageboy on 5,680 views
Remco NCrunch Developer
#6220
23 Aug 2014 10:33 UTC
Hi,
This is by design, as the workspaces are intended to be transient and regularly cleaned up. NCrunch does actually go to some pain to make sure the workspaces are cleaned up. On shut down it will launch a process that cleans up the workspaces about 10 seconds after the IDE shuts down (to ensure no problems with file locking), and it will also remove any existing workspaces when the IDE is next started (in the event it was terminated unexpectedly).
The motives behind ensuring the workspaces are cleaned up include preventing NCrunch from consuming excessive amounts of disk space and to create a solid perception that the tool cleans up after itself (which is EXTREMELY important for developers as otherwise they'll delete the workspaces manually, causing problems).
Re-using the workspaces IS programmatically possible through hash-checking etc, but it is technically difficult to do reliably and in a consistent way that people will understand. It's something that's been considered as a feature, but probably won't be introduced soon unless people voice a strong demand for it.
The behaviour of NCrunch's workspacing hasn't changed since v1. I wonder if it's possible that you're noticing this now much more due to the size of the solution and use of a custom workspace base path?
This is by design, as the workspaces are intended to be transient and regularly cleaned up. NCrunch does actually go to some pain to make sure the workspaces are cleaned up. On shut down it will launch a process that cleans up the workspaces about 10 seconds after the IDE shuts down (to ensure no problems with file locking), and it will also remove any existing workspaces when the IDE is next started (in the event it was terminated unexpectedly).
The motives behind ensuring the workspaces are cleaned up include preventing NCrunch from consuming excessive amounts of disk space and to create a solid perception that the tool cleans up after itself (which is EXTREMELY important for developers as otherwise they'll delete the workspaces manually, causing problems).
Re-using the workspaces IS programmatically possible through hash-checking etc, but it is technically difficult to do reliably and in a consistent way that people will understand. It's something that's been considered as a feature, but probably won't be introduced soon unless people voice a strong demand for it.
The behaviour of NCrunch's workspacing hasn't changed since v1. I wonder if it's possible that you're noticing this now much more due to the size of the solution and use of a custom workspace base path?
Thanks for the quick reply,
It's not a big deal, I was actually more worried that something in our somewhat complex build was causing NCrunch to do this.
If this intentional, I have no problem with it.
Is this behavior explicitly mentioned somewhere in the documentation?
Did I miss it?
It's not a big deal, I was actually more worried that something in our somewhat complex build was causing NCrunch to do this.
If this intentional, I have no problem with it.
Is this behavior explicitly mentioned somewhere in the documentation?
Did I miss it?
Remco NCrunch Developer
#6224
24 Aug 2014 11:29 UTC
Ok :) Thinking about the related thread you've posted regarding the space consumed by assembly references, I have a feeling that having the static reference copying turned off will probably make a very big difference in your initial build time.
The upcoming v2.8 release does have a number of improvements targeting engine startup times... although the effectiveness of these improvements will be very dependent upon where the bottlenecks are in the first startup run. I have a feeling that in your case the slow initialisation results more from the workspace creation and initial build, rather than the NCrunch kicking itself to life.
There is some mention in the documentation of the workspaces being cleaned up on exit, although this isn't clearly explained and I'm sure it's easily missed or not understood.
The upcoming v2.8 release does have a number of improvements targeting engine startup times... although the effectiveness of these improvements will be very dependent upon where the bottlenecks are in the first startup run. I have a feeling that in your case the slow initialisation results more from the workspace creation and initial build, rather than the NCrunch kicking itself to life.
There is some mention in the documentation of the workspaces being cleaned up on exit, although this isn't clearly explained and I'm sure it's easily missed or not understood.
Post a reply
Log in to reply.