Default Native Library Name about glfw-net

[MarkWilds]

Cant we add and dll.config like https://github.com/opentk/opentk/blob/master/src/OpenTK/OpenTK.dll.config?

We can configure the new .csproj files to automatically copy this file the output directory.

[ForeverZer0]

AFAIK, the DLL map is framework dependent, and the way that Mono handles resolving native libraries. .NET Core uses AssemblyLoadContext, as well as there are cross-framework implementations like NativeLibraryLoader. For some reason or another, .NET Core rejected the idea of implementing (see here and links within issue). Supposedly .NET Core 3.0 will be making some major improvements to this issue.

Changing the library name in this library will have no real effect, as the above mentioned methods will still need to be implemented if your application targets multiple frameworks and platforms. By changing the default name to drop the version suffix, it will allow Unix platforms to need no extra resolving. A Windows user will likely need to resolve the path regardless, as their are multiple binaries for x86 and x64.

By changing the name, it is basically a win-win. Nothing really changes on Windows platforms, worse-case scenario they need to edit the library name, and it will allow it to be found automatically on Unix platforms without need for resolving.

As stated above, the actual technique for resolving the library is going to be dependent on the application that uses it, and goes beyond the scope of any .NET Standard library. .NET Framework, .NET Core, and Mono all handle this differently. The name change will simply limit the number of scenarios where automatic resolving fails it need to go to a fallback in user-code, whatever way that will be.

EDIT:
After writing this and doing some thinking, I did come across this for .NET Core. Another option would be to create a few more solutions that target different frameworks, and account for each. Will definitely keep in consideration. .NET Core has been my target primary framework, so glad to see the DllMap feature added there.

[ForeverZer0]

Closing this for now.
Will likely revisit the idea with the official release of .NET Core 3.0, and the new features that will be including for native library resolving (the preview release has issues on my Linux machine for proper testing).

[Rjvs]

@ForeverZer0 open this again for .Net Core now that 3.1 is out?

[ForeverZer0]

@Rjvs

Good call, will do. Work on this has been agonizingly slow, just life happening, but will be done in the foreseeable future.