Hi, thanks for sharing this issue.

Switching branches is a very complex action as it causes a massive cascade of changes to be run through the system in rapid sequence. The engine does its best to track every individual change and respond to it, but there are some known issues that can cause desynchronisation, especially around rapid changes to project XML.

My general advice is to switch off NCrunch if you trigger a task that results in large scale source code changes (such as a Nuget update or VCS action). I appreciate that this is far from ideal as NCrunch can take a minute or more to initialise when being used on larger solutions.

With that said, getting NCrunch to handle situations like this is always a goal. Any more information you can give me on the change patterns that cause a desync will always be very welcome.

When you perform a branch switch (which I assume consistently recreates the problem for you?), do you wait for the VCS action to completely finish before asking VS to reload the projects?

This will definitely create problems for you. NCrunch doesn't automatically restore Nuget packages as part of its build - for good reason. NCrunch only builds projects inside its workspaces, and as each workspace is effectively transient and may have many copies, this would result in NCrunch downloading the same packages multiple times unnecessarily. The engine did actually used to do this - it utterly annihilated performance.



I'm aware of an issue in which a missing assembly reference can cause a desync. The issue arises because NCrunch is dependent upon MSBuild to tell it about the assemblies being referenced by a project, and MSBuild won't report assembly references that don't exist - it simply ignores them. You'll find you notice this when attempting to build a project that has a missing assembly reference; the compile errors give you an unsure message of 'Perhaps you are missing an assembly reference?'. This is because MSBuild has simply dropped the missing reference from the parameters passed into the compiler, so the compiler isn't sure whether the referenced file is missing or the reference just doesn't exist at all.

So anyway, when MSBuild doesn't tell NCrunch about a missing reference, NCrunch simply assumes the reference doesn't exist. This prevents it from tracking the filespace where the referenced DLL should be, making NCrunch completely ignorant of the assembly when it is then added at a later time. The end result is:

1. You switch branches in your VCS.
2. The Nuget DLLs being referenced by the original code are removed. The code now references DLLs that don't exist.
3. NCrunch reloads the projects that have been changed and queries MSBuild to establish the list of references. The missing DLLS are not included in this list making NCrunch unaware of them.
4. You rebuild your solution in VS, and the referenced DLLs are restored by Nuget.
5. NCrunch isn't aware that the references now exist and needs to reload the projects before it is aware of them.

This is the sole desync scenario that I'm aware of at the moment. It's possible that there are more, and if you can find them, please do share any more details you have. The above issue is extremely challenging to solve without breaking down vital abstractions and introducing other problems, but I'm certain that it will be giving you no end of trouble with your workflow.

Have you considered having separate cloned repositories in different areas of your disk to represent the different branches? If you're able to avoid needing to switch branches under your tooling, this could save considerable pain.