Usually this problem is caused by absolute file path references that reach out from NCrunch's workspace and manipulate files that exist in your original solution directory.
Make sure you don't have any build steps or tests that access files using absolute file paths. In order for NCrunch to isolate components for testing, all files must be accessed using relative references so that they can be safely included in the workspace. Otherwise, the act of NCrunch building your project or running your tests will result in changes to your original solution, which in turn causes NCrunch to detect those changes, and run everything again (because it's different).
Thanks! This is what I suspected. I inherited this project recently and have looked through all the project configuration and can't find anything that looks like it would be triggering this, but I appreciate your confirmation that this is the likely culprit. I'll push forth.
If the nuget.packages.config file is the culprit, I think the key issue here would be trying to identify why the SetBasicInformationFile is being performed against the nuget.packages.config file in your foreground solution directory instead of in the NCrunch workspace.
Make sure than when you're monitoring the build in procmon, you monitor the NCrunch build and not the Visual Studio build (sorry if you're already doing this, I just thought I'd point it out to be safe).
There are a couple of tricks that can often be used to find absolute references:
1. Try renaming your solution directory (i.e. put it somewhere else. If there is an absolute self-reference anywhere pointing to it, something will blow up with an error during your normal non-NCrunch build/test run when you do this)
2. Set all your source files to read only (avoiding any files that are output from your build). In theory, this should cause something to blow up if it tries to alter your source files as part of the build (which is bad practice anyway). This is probably harder to get right than option 1.
I did some more hunting with procmon and noticed this event over and over as well:
10:20:02.9745792 AM nCrunch.BuildHost.x86.exe 6972 IRP_MJ_CREATE \\ourdomain.net\users\Users-N\NCraddock Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a File System NAME INVALID
I never get an error or anything, but it's confusing because that path shouldn't be figuring in to anything. Nothing is on that path and nothing references anything on that path.
Although I'd say that accessing a file in this location is probably undesirable (and is something you should look at), I don't think that this is directly related to the recursive build issue you've described. In order for NCrunch to keep rebuilding the same project, it must be referencing your original location on disk (which I presume isn't on a shared network drive?).
Would you be able to push through a bug report while NCrunch is doing its crazy building? I may be able to tell from the log file which file is triggering the change.