Runtime: DllImport from DYLD_LIBRARY_PATH on OSX

[huysentruitw]

We are using [DllImport("some.dll")] to interop with a 3rd-party library which we cannot redistribute ourselfs because of license restrictions. Our application needs to run on Windows, macOSX and Linux.

Therefore, we require that the path to the installed some.dll is added to the PATH / LD_LIBRARY_PATH / DYLD_LIBRARY_PATH environment variable in order for our application to find the DLL.

However, on macOSX, since the latest x versions, they tend to purge the DYLD_LIBRARY_PATH environment variable for spawned / child processes as part of their System Integrity Protection. Which is the case when we start our .NET Core application through VS Code or npm run <command> etc.

This means it is impossible to load a DLL that is not in the current application directory using DllImport.

Is their any solution to this issue?

[jkoritzinsky]

If you can load the library via dlopen, then you should be able to use a combination of System.Runtime.InteropServices.NativeLibrary.Load to load the library, NativeLibrary.GetExport to get the entry point, and Marshal.GetDelegateForFunctionPointer to create a delegate that wraps the native pointer similar to a P/Invoke. The overload of NativeLibrary.Load that just takes a string is more or less a direct call to dlopen.

[AaronRobinsonMSFT]

@huysentruitw If you are looking to continue to use the DllImport attribute, it is also possible to set a callback using NativeLibrary.SetDllImportResolver.

/cc @vitek-karas @elinor-fung

[huysentruitw]

@jkoritzinsky:
Thank you for your answer but I don't think moving away from DllImport is even something we can consider, we're talking about 100+ imported methods.

@AaronRobinsonMSFT:
Thanks for pointing me to SetDllImportResolver, had no idea of its existence, looks like that should to the trick.

Closing the issue for now.