[Feature request] NativeAOT static linking improvements

[NotNite]

Hi! I'm using Hexa.NET.ImGui in a new project. This is a runtime hook for a game using DirectX 9, built using NativeAOT and using static linking. I thought I'd share some feedback I had with getting Hexa.NET.ImGui to work:

• Static linking assumes that the exports are present in the main module of the process. Because my project is a mod injected into another game, this assumption is false and the APIs crash the process (since the resolved addresses are zero). It would be nice to configure the process module in the ImGuiConfig global, where the default (null, probably) could fall back to the main process like it currently does.
• The static libraries for ImGui are not shipped with Hexa.NET.ImGui and are instead present in a folder in this repository. I like to keep binaries out of my source tree unless absolutely necessary, so it'd be nice if there was a way to ship them on NuGet and either toggle static linking on with a property or ship the static libraries in an extra package (not sure how DirectPInvoke interacts through dependencies though).
• I had to build cimgui from source since my target platform is x86 Windows and the example is x64 Windows. Configuring cimgui right in the first place is annoying (especially matching ImGui version), and it took a lot of hassle. While the CI in this repository currently builds dynamic libraries, it'd be appreciated if they could output static libraries as well, so I don't have to go through this process again (and there's a cleaner chain of trust for the built libraries).
• Building the backends statically can be a headache, which would probably cause issues for a potential CI setup. I had issues configuring cimgui to include & export the backends properly, and the export names don't match what this library expects (the generator assumes the exports start with a C which I had to work around).
• There's a lot of extra libraries to be included when building with FreeType support (who would've guessed me asking for that would come back to annoy me later). This wouldn't really be a problem if the static libraries were already distributed, but I thought I'd mention it as an added pain point for self-packaging static libraries.

Thanks!

[JunaMeinhold]

Hi, thanks for your feedback!

• I’m planning to implement a solution where I don't need to manually create the XXXConfig class. It will be centralized, similar to the LibraryLoader.InterceptLibraryName API, which will be available across all libraries of the Hexa.NET.* family.

• Shipping static libraries via NuGet is something I’m unsure about. My intuition tells me that it might not work due to the way static linking functions, but I’ll check that later.

• I’ll set up a GitHub Actions pipeline to build the static libraries, including dependencies like FreeType.

• The reason the generator uses the C prefix is that it parses the C header from here. This wrapper is necessary for building the shared library, as ImGui makes it impossible to export the functions directly without modifying the ImGui source.

Thanks again for your valuable input!