rlawley;10781 wrote:
I'm not aware of my tests having any background code, and this certainly isn't something which has changed recently if any do. Is this a feature recently added to ncrunch?
Yes. This was added in NCrunch V3.0 with the improved impact detection. The feature isn't critical to the rest of the impact detection working, so it's entirely feasible to just leave it switched off if it's causing problems. Because the feature itself works by hooking very low level APIs, there's a high chance of unknown constraints affecting it and causing unexpected behaviour. This is why a configuration switch was added to allow you to turn it off - I wasn't 100% confident that it would work in all scenarios.
rlawley;10781 wrote:
I tried to do a bit more digging but am having trouble isolating any specific tests which cause it. It's not the test that I'm changing which is causing things to fail (though I do have engine mode set on Run All Tests Automatically, as sometimes I notice Impacted only doesn't find some).
Because it works at a very low level, it might not be your test code that's causing the file access, or even the code under test. There could be other activity inside the .EXE process that accesses the file system. For example, something internal in .NET or the O/S itself. Maybe even a virus scanner or other resident software.
rlawley;10781 wrote:
I suspect the only way to easily find this is for you to trap that exception and report a warning on the test which was running at the time. While it's the user's fault if a test does something post-execution, at the moment it's stopping ncrunch from working at all on solutions where this happens.
If you set your 'Log verbosity' setting to 'Detailed', you'll be able to find a more detailed log of the entire test execution (with its errors) run inside the NCrunch Processing Queue Window. It might be possible from this to work out which test(s) are related to the problem.
My general recommendation is that unless you're leaning heavily on this feature, it's probably most time efficient to just turn it off. This is likely to be one of those intermittent, data related issues that could be very time consuming to track down and may not even be possible to fix it, assuming we can find it.
