Hi, thanks for sharing this issue.

The short answer to this is that we actually can't reliably support large branch switches without a reset of the NCrunch engine.

The long answer is that after trying to tackle this particular problem for the better part of 14 years, we haven't found a way to make it work correctly with newer versions of Visual Studio as the platform simply isn't designed with this sort of thing in mind. Presently we have 4 different synchronisation systems all working in parallel to try and keep NCrunch updated with the in-memory state of the codebase in VS. We integrate with the automation interfaces, the package interfaces, the CPS project system and the file system. No one of these provides us with all we need, and the handling changes between each version of VS. Since VS2012, the entire project system is multi-threaded and we have a range of crazy workarounds in place to try and allow the engine to align itself through the numerous reliability problems that have been introduced and fixed in different versions of VS over the years. Since VS2017, VS performs a background package-restore on projects when it loads them (but not all the time), the behaviour and timing of which depends on the VS version, and sometimes it actually doesn't work, so VS itself gets confused about the state of the projects .. sometimes to the point where it even crashes. Should the stars ever align and VS has a build that can handle branch switches and we can too, it won't stay that way. The project/dependency system appears to be one of the most complex parts of VS and it also changes all the time. I mention all this not because I expect it's helpful for you, but more because I want you to understand that I'm not just trying to push this issue away: We actually have no feasible way to implement it.

If you need to switch branches regularly, I suggest having two separate checkouts of your codebase on disk, one for each branch. You can then have two IDEs open, one for each branch. This will also alleviate the problem of having a single NCrunch cache file shared between branches, which would result in all your tests needing to be re-run every time you switch branch. I accept that this is a very resource intensive way to work (given the memory footprint of both VS and NCrunch), but it might be a viable way to work if you have the hardware to handle it.