Future of dllmap / NativeLibrary?

[TheSpydog]

I work on a game framework that makes use of Mono's dllmap feature for supporting varying native library names across different platforms. I've found the dllmap mechanism to be plenty sufficient for the needs of the project (and far simpler to use than .NET Core's NativeLibrary API), but I'm wondering how future-proof it is.

Since .NET Core 3.0 introduced NativeLibrary, and the Core and Mono runtimes are in the process of being unified for .NET 5+, is dllmap going to be removed from Mono in favor of NativeLibrary? Or will they coexist? Or will NativeLibrary be exclusive to .NET Core?

[filipnavara]

First of all, NativeLibrary works on all .NET 5 runtimes (CoreCLR, Mono and CoreRT). The Mono DllMap code is currently disabled in the .NET 5 code base.

I don't think there is concensus on whether the DllMap support will be re-enabled or not. It may still be useful for AOT compilation where the declarative approach can be evaluated at compile time easily. For CoreCLR there were originally plans to reimplement DllMap on top of NativeLibrary functionality but as far as I know they never materialized.

Note that it is possible to combine the loading flexibility of NativeLibrary with the traditional P/Invoke approach. For example, the System.Drawing.Common library does that.

[TheSpydog]

First of all, NativeLibrary works on all .NET 5 runtimes (CoreCLR, Mono and CoreRT).

Ah, good to know!

I don't think there is concensus on whether the DllMap support will be re-enabled or not.

I'm curious why it wouldn't be re-enabled? CoreCLR I understand since the feature didn't exist in the first place, but for Mono, why remove something that's already implemented and is known to work?

For CoreCLR there were originally plans to reimplement DllMap on top of NativeLibrary functionality but as far as I know they never materialized.

That's a shame, having a built-in compatibility shim seems like a great solution.

[filipnavara]

I'm curious why it wouldn't be re-enabled? CoreCLR I understand since the feature didn't exist in the first place, but for Mono, why remove something that's already implemented and is known to work?

Both the native library loading code and the assembly loading code was substantially reworked to align the behavior with CoreCLR and add support for the new APIs (NativeLoader, AssemblyLoadContext). It now follows the same file name fallback logic (eg. trying "lib" prefixes, ".dll"/".dylib"/".so" suffixes, "libc" fallback, etc.). The simple answer is that the baseline was to match CoreCLR APIs in this regard. Adding DllMap back into the mix would not be too difficult (in fact, it was already prototyped once) but the focus currently seems on getting all the libraries working perfectly on the new Mono runtime (https://github.com/dotnet/runtime/projects/48), especially on mobile platforms.

[jkotas]

Duplicate of #37213 that has more in-depth discussion on this topic.