Push to .NET 10 + removed .NET standard support

[Static-Codes]

Due to requirements of my project, i've ported your code to .NET 10 on the core side.

I was unable to update the .NET Framework solution version as im on Linux, so for my personal fork I simply removed NativeFileDialogSharpSandboxNetFramework feel free to ignore this if you decide to merge this request.

Have a great day, and thank you very much for your work, ill credit you here
https://github.com/Static-Codes/BrowserAutomationMaster/blob/stable/CREDITS.md

[milleniumbug]

Hi, does the existing code... not run on .NET 10? The existing solution should be forward-compatible, although maybe I am missing something on the specifics between DllImportAttribute and LibraryImportAttribute?

[Static-Codes]

I have been having issues with integration, although, I don't believe it is on your end.

Regarding DllImportAttribute vs LibraryImportAttribute, Microsoft states the following,

"In most cases, the use of LibraryImportAttribute requires an explicit declaration rather than relying on default settings. This design is intentional and helps avoid unintended behavior in interop scenarios."

Per: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/best-practices

To my knowledge it is a difference in precision.

I will further update you shortly, as I'm trying another method of implementation.

[Static-Codes]

So I was able to get the NFD working as intended but I had to manually copy the compiled runtime libraries (libnfd.so, libnfd.dylib, nfd.dll, etc) into the bin directory of the project im trying to add NFD support to.

I'm assuming I can just add logic to copy these files during compilation, once I figure that out, i'll go back and test your current codebase on net10.

[Static-Codes]

Took me longer than I originally anticipated, as such, I will have to do the net6 forward compatibility test tomorrow.

Here's the commit in question if you're curious:
Static-Codes/BrowserAutomationMaster@7b045c3

Thank you once again!

[milleniumbug]

Oh, I see what's going on. Originally the project was designed so the NativeFileDialogSharp class library could be built and packed into a NuGet package with dotnet pack (and then the package would be either uploaded to nuget.org or put into a directory you can set locally as your nuget package source). Installing the NuGet package into your application project would put the runtimes directory into output directory, from where .NET is able to load the native DLLs.

Vendoring the library like you seem to be doing isn't a scenario I considered, although I'm not opposed to making it work either (when I figure it out how to make it work without breaking existing code)

[Static-Codes]

Yes! I originally tried via the NuGet package, however, due to the lack of osx-arm64 in NativeFileDialogSharp I was trying to not only port the codebase to NET10, but add osx-arm64 support.

I greatly appreciate the offer to modify your build processes, I would like to instead offer my assistance in adding osx-arm64 to your project.

My assumption is that you don't have an M-Series Mac (please correct me if this is incorrect), as such, I can use my friends m4 mac to do compatibility testing.

I've found a precompiled and universal build of libnfd.dylib in a FOSS project under the MIT license, so I would assume it is safe to use this available resource.

Link:
https://github.com/SamsidParty/IgniteView/blob/main/IgniteView.FileDialogs/iv2runtime/osx-universal/native/libnfd.dylib