"Copy Referenced Assemblies To Workspace" seems to do the trick, but has obvious disadvantages. Is there a better way?

Being able to test multiple RIDs is very similar to being able to test multiple target frameworks, but if it isn't already supported then that would be a feature request.

When the nuget package contains a native dll in /runtimes/{RID}/native/foo.dll and the top level application or unit test project is built with that RID either by specifying in the csproj <RuntimeIdentifier>{RID}</RuntimeIdentifier> or on the command line with dotnet build -r {RID} (I think msbuild /p:RuntimeIdentifier={RID} also works) the native dll is placed in the output directory. From that point, the .net dll from the nuget package can contain P/Invoke with [DllImport("foo")] in order to import the exported native function, and consumers of the nuget package can just use the nuget package like a normal .net package, as long as they set the RID on the application or unit test project.

If building without the RID, the .net wrapper library that contains the P/Invoke will be deployed to the output directory, but the native library will not, in which case it will throw an exception: System.DllNotFoundException: Unable to load DLL 'foo'

You can also specify multiple RIDs in the csproj e.g. <RuntimeIdentifiers>win-x86;win-x64;linux-x64</RuntimeIdentifiers> and then dotnet build (or dotnet publish -r {RID}) will produce an output directory for each RID, each with the appropriate assemblies, in a similar way to <TargetFrameworks>

It may just be because NCrunch is using msbuild (I assume) rather than dotnet build, and dotnet build is probably doing something on top of what msbuild does. Passing the RuntimeIdentifier/RuntimeIdentifiers properties from the csproj to msbuild /p: may fix it, or switching to dotnet build, perhaps by an option in the NCrunch project config.

Hi Remco.

I'm using the current version (4.16.0.4) and stumbled over the same MSBuild error yesterday. My colleague started to use single file deployment which required the RID somehow. I've added a "dotnet restore -r win-x64" as prebuild event to our project to run a restore with RID explicitly as workaround.

What's the current state regarding runtime identifier support? Do you plan to respect the RuntimeIdentifier element in the project file? E.g. by running "dotnet restore" or MSBuild with the runtime identifier internally.

Best regards,
Thomas

Hi Remco.

I confirm that 'Copy referenced assemblies to workspace' solves my issue, too.

I'm using this approach now. Using 'dotnet restore' as pre-build event was just the first working fix I've found.

Best regards,
Thomas

PS: Another solution should work, too: Use conditional build behavior like $NCrunch to fall back to old project setup without single file deployment and RID usage.