Hi, thanks for posting!
Getting NCrunch to run against a large and well established established project that wasn't built with NCrunch in mind can sometimes be challenging. Even more so if you haven't been involved from the project since its first inception.
The best thing I can recommend is to make sure you read through the documentation thoroughly (especially the troubleshooting guides at
https://www.ncrunch.net/...ng_project-build-issues and
https://www.ncrunch.net/...-runtime-related-issues). This will help you to gain and understand of how NCrunch works and which aspects of your project may experience difficulty.
Large integration tests (https://www.ncrunch.net/documentation/guides_integration-testing) that work cross-process can't be efficiently tracked by NCrunch, as the code coverage is occurring outside NCrunch's task runner executables. Generally the practice I would suggest is to try to use cross process tests only to confirm that the wiring between your processes is working correctly, and try to rely on unit tests to test the actual logic inside the same process - this way you'll have inline code coverage. However, with that said, it is always still possible to have the tests running with NCrunch as you would with any other test runner.
Generally speaking, the problems most often experienced with cross-process integration tests are around their initialisation. Cross process tests have a tendency to make use of implicit dependencies to other files in your solution, or they make assumptions about the known location of other binaries. Both of these situations can require additional configuration in NCrunch, as NCrunch needs to be aware of implicit dependencies (via the 'Additional Files To Include' configuration option), and it will also avoid copying referenced dependencies into build output directories unless the 'Copy referenced assemblies to workspace' configuration option is set. I would definitely recommend you try turning this option on for ALL the projects in your solution, as it will allow you to immediately rule out any issues that might be created by this behaviour (you can always do some work later to allow you to switch it off, thus improving performance).
Also make sure you check carefully the logic inside any initialisation and teardown fixtures, as exceptions thrown here can cause NCrunch to throw blanket errors like the one you've described.
I hope this helps!
Cheers,
Remco
