Consider using Native Library Loading

[eXpl0it3r]

Using p/invoke with DllImportAttribute is a bit cumbersome in a cross-platform manner.

As such, it might make sense to use the NativeLibrary class instead.

References

• https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cross-platform
• https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=net-6.0
• Native Library Loader API dotnet/runtime#27267
• Handling p/invokes for different platforms and discussions about dllmap dotnet/runtime#4216

[DemoXinMC]

I'm a bit confused on the benefit of this.

In addition to the large scale rewrite of P/Invoke definitions, wouldn't this also either require users to manually call some static method we create like SFML.Modules.LoadLibrary()(name just made up) or add their own NativeLibrary.Load("sfml-system.dll"); at the start of their program?

What do we gain out of this change?

[eXpl0it3r]

Having to workaround limitations of DllImport again (see #247), I seem to understand the underlying problem a bit better.

We can provide a single name to DllImport and then have to hope that InteropServices does the correct thing in resolving the libraries cross-platform. As an example for csfml-graphics it would need to find on Windows csfml-graphics.dll, on Linux libcsfml-graphics.so, and on macOS libcsfml-graphics.dylib, but that in a specific directory, that is the bin/<Config>/<TargetFramework>/runtimes/<RID>/native/.

While it actually gets pretty close, looks in all those directories, it fails to look for the right combination - in my opinion a bug. Thus it forces us to ship libraries without suffix, e.g. libcsfml-graphics on Linux and macOS.

There's one potential workaround and that is to use write our own Custom Import Resolver, so we can define ourselves what is being looked for: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/native-library-loading#custom-import-resolver

The use of Native Library Loading was just another idea, that I don't fully understand (yet) and might not be suitable.

I'm wrong. I think the main confusing with all of this is, that if the native lib is found, but then fails to load due to a missing dependency, DllImport will simply continue loading other libraries. The messaging around this is not very clear, so at a glance it appears as if the specific library was never considered, while it was actually always a dependency issue.

This now also allowed me to revert the change made regarding extension fixing in CSFML.

[eXpl0it3r]

I don't necessarily think Native Library Loading is needed and may actually not make sense. If we need to influence the loading behavior we may probably first want to write our own Custom Import Resolver.

As such, I'll close this issue for now.