Hi Remco,
I do understand the technical difficulties that you are describing below, and I'm fine with turning off the static
reference copying, as I have dome, in order to be able to use a ram-drive, but at least from my perspective, changing references WHILE tests are building doesn't feel like the most common scenario, i.e. waiting an additional minute for all projects "sharing" _ncrunchreferences to finish building/testing when I update a binary package, which isn't a very common thing that happens in the development lifecycle sounds like a fairly small loss, when compared with filling a 4GB ramdrive during normal operation, but that's me.
Again, If this were some minor optimization, I wouldn't care, but for most users, sacrificing 4GB of diskspace (or in my case RAM) just to save that minute in case they upgrade a binary package sounds like an easy thing.
More over, if I have many projects referencing the same binary .dll and some of them are in the process of building/testing, I'd even venture and say that it's would be preferable to kill those projects and restart the compilation from scratch (there by not even waiting those 30 seconds) because the previous tests/build are probably meaningless given that a binary dependency has just changed.
Anyway, not a huge deal either way.
Remco;6221 wrote:Hi,
Unfortunately, re-use of the _ncrunchreferences directory just isn't technically feasible with the way that NCrunch works.
NCrunch works very hard to isolate projects from each other inside the workspaces, as they need to be able to be built independently and dynamically strung together to form application domains for testing. Sharing references between projects would breach this isolation and create potential problems.
For example, let's just say you have a test inside Project1.csproj that takes 30 seconds to run and makes use of an assembly called MyReference.dll.
MyReference.dll is also used by a test inside Project2.csproj, which is logically very different to Project1.csproj and isn't related in any way. It just happens to reference the same DLL file.
Now, let's just say that the 30 second test is running in the background (as NCrunch does), and you perform an action on your foreground solution that changes MyReference.dll in some way (could be a VCS update or something similar).
NCrunch would immediately detect this change, and recognise that it needs to rebuild Project1.csproj and Project2.csproj, then re-run any applicable tests.
If the assembly file is being shared between all workspaces, NCrunch then cannot update this file until it is no longer being used by any tests under execution. This means the engine basically stalls for 30 seconds to wait for the test to complete execution before it can start rebuilding and reworking. The tests in both Project1.csproj and Project2.csproj cannot start executing until the original test run has finished.
If the assembly file is not shared, NCrunch can just build new workspaces as it needs to in order to support concurrent action. The existing workspace containing the old file which is used by the test will be immediately recycled and updated after the test has finished executing.
I hope this makes sense.
Cheers,
Remco
