Recent commit "Enumerate available fonts through the native API on macOS" breaks UWP native build.

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of Fonts
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

A recent commit “Enumerate available fonts through the native API on macOS” breaks the UWP native/optimized build. The compilation goes ok, but when running, the application will produce the following error message:

---

UwpConsoleApp.exe - System Error

The code execution cannot proceed because D:\System\Library\Frameworks\CoreFoundation.framework\Versions\A\CoreFoundation.dll was not found. Reinstalling the program may fix this problem.

OK

Steps to Reproduce

Start VS 2019 (not later versions). Then choose menu Extensions -> Manage Extensions, and from Visual Studio Market place add the extension template “Console App (Universal) Project Template…”. Also install the “Classic ‘New Project’ Dialog” extension, and enable it in Tools -> Options -> Classic Project Dialog -> Check the “Use Classic New Project Dialog” . Now you can create an UWP C# console app. Change the build to release mode, x64, make sure the “Compile with .NET Native toolchain” and “Optimize code” checkboxes are checked in the project build properties. Now compile and run, and it should run OK.

Now add a reference to SixLabors.Fonts 1.0.0-beta19. Recompile and run again. Now the error should occur.

Note that the problem does not happen when the “Optimize code” checkbox is not checked. In debug mode the app will run OK.

System Configuration

Windows 10, VS 2019.

• Fonts version:
• Other Six Labors packages and versions:
• Environment (Operating system, version and so on):
• .NET Framework version:
• Additional information:

The issue first started to happen in 1.0.0-beta17. Version 1.0.0-beta16 is ok. I’ve further pinpointed the source to be the following commit: https://github.com/SixLabors/Fonts/commit/5bc3f05be1996e1d05b2d44b56434d511b6fd49e.

So when running on windows, UWP will fail because it cannot find the specific MacOS dll.

My first thought is to separate all native calls in a separate nuget package so that you can just omit that nuget package reference when compiling an UWP app.

[Sergio0694]

“This seems clearly a bad idea then.”

It’s a consequence of .NET Native using static imports only, which would explode if a .dll is missing, so all such cases are just rewritten to be throw stubs during assembly loading instead. That is, .NET Native doesn’t have runtime library loading capability, so if a .dll is missing when the application is built it means there’s no way it could ever be available at runtime.

“Can we get that fixed?”

Unfortunately no, not likely. The fix was to support library loading, which was actually implemented internally, but then funding was cut and the entire .NET Native interop team left Microsoft, and now the whole project is now in maintenance mode 🥲

[0xced]

Thank you @MichalStrehovsky for chiming in, I have submitted #309 which should fix this issue in the easiest way possible.

I guess I chose to use ExactSpelling = true in the first place because there’s no reason to try any other name variation on macOS. I had no idea that this would be a problem for .NET native. 😲