Resolution of native libraries when using DllImport

TL;DR: How can I make DllImport automatically load the right native library from the runtimes/<rid>/native path when it is in a project referred by ProjectReference, similar to what PackageReference enables by adding the appropriate resolution information in deps.json?

–

If I create a NuGet package and put native DLLs in runtimes/<rid>/native/, the deps.json file generated for the assembly referencing that package will get runtimeTargets entries for the native libraries, allowing DllImport to find the appropriate DLLs to load. That mechanism is very useful for easily targeting multiple platforms with “Any CPU” despite reliance on native libraries that are each specific to a platform/architecture combination.

Now I would like to unit-test the classes in that package. Usually I put the unit test project in the same solution, make it refer to the project containing the classes to test. Unfortunately, that doesn’t bring the mechanisms from PackageReference, as it only uses a ProjectReference. Therefore the deps.json for the unit test assembly doesn’t get hints for the native libraries, and when the unit test is run, it complains about not finding the native DLLs.

A workaround would be to have a separate NuGet package containg nothing more than the native libraries, making the project containing .NET code refer to it, similar to what libgit2sharp does. However that’s not convenient when updating the native libraries because it requires publishing their package before being able to test their integration in the .NET code. I know about the NativeLibrary class where one can register a custom resolver, but that seems tedious for true multiplatform. I didn’t find a simple way to replicate the RID-based resolution.

Is there any other way? Any thoughts?

[saucecontrol]

I think the core of the problem is lack of support for RID specific assets our project system

I think the native binary resolution is just a symptom of a larger problem, which is that when consuming a project that builds a NuGet package as a ProjectReference, none of the package behaviors are brought in. That includes not just RID-specific binaries but also .props and .targets. Perhaps the answer is that things that are expressed by convention (file name/path, etc) in NuGet packages need to be able to be made explicit in the project file so they can be consumed by the SDK. That could also drive the package definition so that less of it is based on magic folder names.

[alexrp]

I’d really urge prioritizing this issue. .NET has an excellent interop story these days … except when it comes to everything build-related. Resolving this issue would bring the story from excellent to amazing. It would also make life massively simpler for those of us who are maintaining MSBuild SDKs that bridge managed and native code.