Interop with Native Client library on MacOS and Linux

[KrzysFR]

The code seem to have some issues loading the fdb_c library on MacOS and Linux.

It looks like the code expects to run on Windows by default, and the static constructor of FdbNative will call UnmanagedLibrary.Load(...) which uses WIN32 specific interop to pre-load the library (LoadLibrary, FreeLibrary)

I think that there's been work done in .NET Core to implement cross-platform library loading support, so maybe we should use this instead? If there's a NuGet package or existing code somewhere that could be reused, we could make it so that it works out of the box on all platform without having to invoke any method at the start.

We may need to check the current platform at runtime to emulate, but I'd like to not have to resort to #if /#else if possible.

[KrzysFR]

There is also some custom logic that try to detect if the fdb_c library file name has been specified in the custom path, by looking for the .dll extension which is windows specific.

I'm not sure if the best approach is to check for all possible library extensions for all platforms, or not... It would be nice to still be able to specify the full path to a specific file.

[abdullin]

According to my previous findings, the easiest way is to:

1. Skip the library pre-loading completely.
2. Refer PInvoke methods to fdb_c, which should be resolved by CLR to fdb_c.dll on Windows, libfdb_c.dylib on OSX and libfdb_c.so on Linux.

Note, that using fdb_c.dll as the PInvoke library target blocks convention-based loading by CLR (it stops on the first dot, if I'm not mistaken).

Combination of DllImport("fdb_c") and disabling path-based library preloading, seems to address the majority of the library use cases. Maybe it is worth making this the default behavior, leaving the option to invoke custom loading on edge cases? Although I'm not sure if this would be a breaking change for many users.

[KrzysFR]

There was an issue specific to the way FoundationDB release the client as part of its setup, and the way path are resolved on Windows. I remember discussing with the devs and the best compromise was the current solution, but it is windows only.

I think the compromise would be to check the platform at runtime, and keep the current behavior for Windows, and do what's required on Linux.

The issue was that the fdb_c.dll was not in the current working directory, and was in one of the path declared in the PATH environment variable. There some slight differences in path resolution between what [DllImport(...)] does, and what the native Win32 LoadLibrary does, hence the current solution to pre-load the library (using LoadLibrary semantics) so that DllImport does not to do anything.

I don't know what is the semantics of a simple [DllImport("fdb_c")] on linux or MacOS: how will it find the libfdb_c.dylib on MacOS?

Since .NET Core is more recent, I suppose that the way they implement DllImport for linux/mac is aligned with the standard for these platforms, but I don't have any experience for this.

I'll try to setup a .NET Core 2.X and VSCode build env on my mac tonight to test things out.

[abdullin]

As I understand, fdb_c (if not found as is) would be translated to libfdb_c.dylib by .NET Core CLR by prepending the common prefix and suffix. It then loading that library from the common folders with the shared libraries (e.g. /usr/local/lib/libfdb_c.dylib on my mac).

E.g. check out this merged PR into the .NET Core CLR: dotnet/coreclr#1248