Hi, thanks for sharing this issue and providing the sample solution.

Interestingly, the code sample seems to work correctly for me. The projects all build and the test passes successfully. I'm not sure if there is perhaps an intermittent pass/fail pattern here, though looking that the dependencies I'm not sure how the code explores the multi-version scenario that you've described.

However, categorically I would expect a test of your description to have major problems under NCrunch. If I understand this correctly, in your environment you have two different versions of an assembly that both have the potential to be targeted by your build system, and you are using run-time configuration to choose the assembly you want inside your test environment. Because of NCrunch's workspacing, it needs to override the run-time resolution of reference assemblies to ensure that the assemblies loaded by the CLR are the same assemblies that were used when the projects were built. A binding redirection in your configuration file would either be ignored or it would disturb NCrunch's control over the test environment with the potential to introduce uncertain behaviour.

I don't expect that it will be possible to get this test working under NCrunch. You may need to change how this code is designed or consider ignoring the test under NCrunch.

Before NCrunch can run tests for your projects, it needs to be able to build them in isolation.

This involves copying all source files and dependencies of your projects into a separate area of the disk. The projects are each separated from their parent solution and isolated so that they can be built independently. To handle this, NCrunch performs a short-circuit build when it loads your projects to identify what their dependencies are and what is required to build them. The only reliable way to identify the correct dependencies for projects at this point is to interrogate the build system, and when the build system is working correctly this will always give a consistent result. In this particular instance, Cassandra v3.1.0.0 is the reference targeted by the build system and therefore it is the assembly that will be used when NCrunch constructs a test environment. Any DLLs that are floating in your bin\debug directories are irrelevant to NCrunch because they are not considered an input to the build system.

If I understand this correctly, the use case you are attempting to test for (incorrect DLL floating in bin\debug directory interfering with reference logic) simply cannot exist in NCrunch's test environment, as NCrunch's test environment is not constructed inside your foreground solution; it is constructed inside a transient and artificial structure that is designed to resemble the project/solution it is sourced from. The reference issue you are testing for can't be tested under NCrunch because it is actually testing your environment, not your code.