Default Native Library Name

[ForeverZer0]

The library name use with the DllImportAttribute to import the functions at run-time currently uses the Windows default naming convention of glfw3, as opposed to its Unix-like counterpart: glfw.

This causes anyone using the library on Linux/Mac to have to manually edit the library name and recompile, since they have no control over the name of native GLFW library as it gets installed on the system.

Since Windows users need only include the pre-built and portable binaries with their application, refactoring the native library name to glfw is trivial, and will not require editing the code or rebuilding, only the library name which they must provide themselves anyway.

Proposal is to change the constant to the Glfw.LIBRARY constant from glfw3 to glfw, so Unix users need only include the library and run it, and Windows users only need to apply a rename to the binaries while adding them to their project.

This should hopefully reduce hassle for everyone on all platforms, and enforce a standardized name "that just works" without all the extra mumbo-jumbo of resolving dependencies at runtime. Windows users will still need to account for CPU architecture and which binary to target, but that is unavoidable.

[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.