Unfortunately there's no way the 'Additional files to include' feature can work with files on a different disk. This is because the feature itself works by copying the files to a location in the NCrunch workspace with an identical relative directory structure when compared to the foreground solution.

Relative paths to files on a different disk are impossible. This means that there's no way you could be referencing these files from your solution using a relative path. The references must be absolute. This means that using the 'Additional files to include' is probably unnecessary, as any code using the files would simply pick them up at their absolute path, ignoring anything copied into the NCrunch workspace anyway.

What kind of results do you get when you run the tests with NCrunch at the moment? Are they unable to find the files?

Thanks, I think I now have a better understanding of the problem you're trying to solve.

The 'Additional files to include' feature wasn't intended to resolve problems such as this, so I suggest steering clear of it. The problem itself is that of an 'implicit co-location dependency' on another project's output assembly. Unfortunately, this is challenging to solve in NCrunch because of the way that it needs to wire test runner application domains together arbitrarily.

You can read more about assembly co-location assumptions and why they are a problem for NCrunch.

In most cases, when I see assembly co-location assumptions such as this, they apply to projects that are actually being referenced by the test project (directly or indirectly). In your case, you have a project that is completely detached from the referencing project and I assume is being loaded dynamically somehow. The good news is that it is still possible to make this work - it's just complicated.

You'll need to tell NCrunch about the implicit dependency between these projects using the implicit project dependencies configuration setting. This will allow you to identify the referenced DLL at test runtime by making a call to NCrunchEnvironment.GetImplicitlyReferencedAssemblyLocations(). You can then choose to either:

1. Adjust your code so that the test can control where the assembly is loaded from, and inject the known path into the code (perhaps via IOC, dependency injection, etc).
... or ...
2. Adjust the test code so that it will copy the file to the same directory as your code is expecting to load it from. Note that if you are doing this, you'll need to be mindful of file locking exceptions if you are running tests in parallel.

If you still need to be able to run the tests outside of NCrunch (where the NCrunchEnvironment service calls won't work), you can enclose the NCrunch-specific code using:

#if NCRUNCH
...
#endif