💡 [Linux] Provide a Flatpak or AppImage release for better distro compatibility

[Sykhasamann]

Is your feature request related to a problem? Please describe.
As a NixOS user (and this applies to other immutable or sandboxed Linux distros), I’m unable to run the current IronyModManager Linux binary.
It depends on dynamic linking and assumes a traditional FHS (Filesystem Hierarchy Standard) layout, which breaks compatibility on distros like NixOS, where the usual /lib or /usr/lib directories are not present in the expected way.

Describe the solution you'd like
It would be great to have an official Flatpak or AppImage release.
Both formats are portable and self-contained, solving compatibility issues across most Linux distributions, especially for users outside of mainstream Debian/Fedora-based systems.

Describe alternatives you've considered
I attempted to patch the ELF binary manually and wrap it in an FHS environment on NixOS using buildFHSEnv and patchelf, but IronyModManager still failed to run due to missing or incompatible dependencies (libssl, ICU, etc.).
Using Wine is not ideal since the app already has a native Linux build.

Additional context
NixOS users often encounter this type of issue when binaries rely on system-wide shared libraries.

A Flatpak or AppImage would help ensure a more robust and accessible experience for users across the Linux ecosystem.

Thank you for the great work on IronyModManager!

[bcssov]

I'm a Windows developer and user, and IronyModManager is developed primarily on Windows using .NET. While I do provide a portable Linux build, I do not support Flatpak, AppImage, or any other sandboxed formats.

There is a community-maintained AUR package for Arch-based systems, but it’s not maintained by me.

Aside from the .NET-related issues you mentioned, other core functionality of Irony might also break in such an environment:

• Reading and writing mod files in user directories
• Accessing and parsing Steam installation data (e.g., libraryfolders.vdf)
• Communicating with Steam to detect login status
• Launching external applications like Steam, file managers (xdg-open), or browsers
• Possibly even clipboard access

These are core features that make Irony what they are. Having said that, I'm willing to make changes to the Irony codebase provided someone else leads the charge here.

[Sykhasamann]

Thanks a lot for your detailed response!

Totally understandable that your main focus is on Windows — and I really appreciate the honesty. I figured as much regarding .NET and the surrounding ecosystem, but thought it was worth asking since the Linux version still runs pretty well in some setups (with a bit of Nix/NixOS wizardry… until it doesn’t 😅).

I completely get the complications with sandboxed environments like Flatpak or AppImage, especially with how Irony interacts with Steam and the file system. That said, it’s awesome to hear that you’d be open to contributions if someone decides to tackle a more portable Linux version — maybe one day someone brave enough will rise 😄

Thanks again, and keep up the great work on Irony — it’s honestly one of the best tools out there for modding Paradox games!

[bcssov]

Just to clarify one point I forgot to mention: while my primary development happens on Windows, I do actively support Linux -- just not sandboxed formats like Flatpak or AppImage. The reason is simple: I don't know enough about how Flatpak or AppImage work and currently don't have the time to dive in and learn them properly.

IronyModManager does run natively on Linux and even includes Wayland support -- something that upstream Avalonia didn't support at the time I added it (about 2–3 years ago). That wouldn't have been possible if I didn't test and care about real Linux environments -- by that I mean non-sandboxed setups like traditional distros that support dotnet and system-wide tools.

So while I don't target immutable or sandboxed platforms like NixOS or Flatpak/AppImage directly, I'm definitely not ignoring Linux users. If someone wants to take on the challenge of extending compatibility to those formats, I'm open to code changes -- as long as they don't break the core experience.