I have a complex system tests project that somewhat tests the results of another project by starting separate processes for that (like a kind of smoke test).

Let's say, that Test_A tests the .NET 6.0 compilation of that project, Test_B tests the .NET 4.6.2 compilation of the project.

The test project itself is in .NET 6.0, but this is independent as it does not directly refer any version of the tested project, but just creates a new process to test them.

I try to use the "Implicit project dependencies" feature for my requirement, but it "uses" only the .NET 6.0 version of the tested project (I guess because the test project is also .NET 6.0): Only the .NET 6.0 version is returned by the "NCrunchEnvironment.GetImplicitlyReferencedAssemblyLocations()", although the .NET 4.6.2 version is also built by NCrunch.

Is there a way to implicitly depend on multiple compilations of a project? If yes, how?

Hi, thanks for posting.

We actually do exactly this for our own testing. As you could probably expect, almost all of NCrunch is multi-targeted and multi-process, so we have tests that bridge between different platforms across IPC boundaries .. for us they are actually very important tests.

So it's definitely possible to do this. It's not necessarily easy, but it's VERY worthwhile. NCrunch's instrumentation (including RDI) is multi-process capabable. As long as your test is responsible for starting the sub-process, it will automatically be included in the session.

The hard part, as you've discovered, is around dependency management. The Implicit Project Dependencies setting is critical for this. Try setting up implicit project dependencies for ALL of the multi-targeted variants you need to reference from the test project, and make sure you do this from the test project itself. If NCrunchEnvironment.GetImplicitlyReferencedAssemblyLocations doesn't give you want you need, try NCrunchEnvironment.GetAllAssemblyLocations instead.

Gotchas include:
* The .NET runtime will permit two assemblies being loaded from different locations under the same name, even if they contain the same types (bad)
* The .NET runtime will also allow an environment to load an assembly that was built for a completely different version of .NET, even though this may be unintentional. This can cause downstream issues (very bad)
* By default, MSBuild will output multi-targeted variants of a project so that they have the same DLL name, even though the path is different. So you can't tell which platform an assembly is targeting simply by its name .. you need to know the path. For the sake of NCrunch, we actually added a suffix onto our assembly names that included the name of the platform, so we wouldn't get tangled with this problem.

Always check the list of loaded modules in your subprocess using a debugger to make sure it is correct.

Given the nature of your project, you're probably already aware of the above nasties but I thought I'd share them anyway as they have caused us years of pain.