Evaluate new installer framework for Windows

[ubruhin]

SUMMARY

So far in my own tests, our installer did run on every Windows but initially it's blocked by some antivirus and requires to click a few (hidden) buttons to start it anyway. It's so cumbersome that some users might not even find this option, thinking the *.exe is a virus.

Another problem is that it seems the installer does not recognize already installed, older versions of LibrePCB. For example if LibrePCB 0.1.7 is installed, and you run the LibrePCB 1.0.0 installer, it reports that the directory "C:\Program Files\LibrePCB" (or something like that) already exists and rejects installing LibrePCB 1.0.0 unless you manually uninstall 0.1.7 first. This is not really user friendly, an installer shall allow to upgrade an installed older application version.

SOLUTION

For the antivirus problem, the most obvious solution would be to sign the installer. However, this costs money and probably it's a bit cumbersome to set it up.

Anyway, I think the main question is whether the Qt installer framework is really the right thing for us. Initially it made sense because we also provided installers for Linux and macOS, so a cross-platform installer framework made things simpler. But starting with LibrePCB 1.0.0, we do not provide these installers anymore, the only installer left is for Windows. So now we could switch to a Windows-only installer framework if there's something better.

Thus I'd propose to evaluate what installer frameworks exist and if they solve our problems. Some criteria:

• FOSS highly preferred
• Not reported as virus, ideally without requiring us to sign it
• Allow upgrading older app versions
• Allow registering *.lpp[z] file extensions
• Somehow I don't like online installers (downloading the app on demand), so offline installation should be supported
• CLI for headless & automated installation, uninstallation & update
• Toolkit installable in our Windows Docker image to allow building the installer on CI
• Maybe support in-app updates (#648)?

Something interesting I already found some time ago is cpack - I didn't look at it in detail yet but it sounds like it is part of CMake, which would be quite nice actually (building the installer right from CMake, and maybe already available in our Docker image?)

[dbrgn]

What about not using a classical installer, but building an MSIX instead? https://learn.microsoft.com/en-us/windows/msix/overview We do that for Threema Desktop, it's quite painless and Windows ships all necessary tools.

Only caveat: Signing is required.

[ubruhin]

Sure, I do not care about the packaging method as long as it fulfills the criteria listed above. But yes, if there's an alternative which doesn't require signing, that would be a very good reason to decide against MSIX.

[dbrgn]

Note: One advantage of a MSIX would be that you can upload it to the Microsoft store. (I'm not sure if that's desireable or not though, in the case of LibrePCB.)

[Dragon1573]

The Windows Package Manager supports MSIX, MSI, and executable installers. Some well known formats (Inno, Nullsoft, WiX, and Burn) provide standard sets of installer switches to provide different installer experiences.

Written in documents of microsoft/winget-pkgs

Despite from uploading package to Microsoft Store, submit a manifest of this package to The Windows Package Manager Community Repository will be another choice. Users can install this package by invoking winget install -s winget LibrePCB.LibrePCB.

[luzpaz]

Solving this issue will make librepcb available to be distributed via winget and chocolatey.

[ubruhin]

Yep, this issue is now part of the NLnet sponsoring, I plan to implement it either for LibrePCB 1.1.0 or (more likely) the following release.

[ubruhin]

So I started with this task now and I think generally we have the following options:

• MSIX: A relatively new package format from Microsoft, built-in into Windows 10 or later. Very convenient to install (no wizard). Allows deployment through Microsoft Store or direct download (including update mechanism). Requires signing!
• MSIXBUNDLE: Basically a bundle of several MSIX files. Allows creating a single file for all architectures (e.g. x86_64 and ARM) which would be convenient for users, but I worry a bit about the file size then (always downloading all architectures although only one is needed). Also the build process is more complicated as CI artifacts would come from different CI runners due to different architectures.
• MSI: Similar to MSIX, but signing is optionally. Not sure if it allows deployment through Microsoft Store (maybe possible today, but not in future) and it doesn't provide a built-in update mechanism.
• Any *.exe installer: There are several installer frameworks which in the end just build a *.exe, NSIS is a very popular one.

I think *.exe installers have the advantage that they will work relatively painless on any existing or upcoming Windows version because binary compatibility between Windows versions is very good. I think we could set up such an installer today and it will still work in 5 years without spending any time for maintenance.

On the other side, I'd prefer something MSI based because it is much cleaner (e.g. easier installation, uninstallation handled by the OS instead of custom *.exe, standardized silent installation, ...). I just worry about compatibility. It seems Microsoft is changing these things all the time and does not care about compatibility too much. Especially for MSIX for me it feels like we (developers and users) are enforced to always work with the latest available Windows version, otherwise it might not work. I really don't like this mindset. Also with MSIX we will have to sign it, so we generate an additional dependency to an external company. Not nice for an open-source project.

So in the end it's a hard decision. All options are painful in my opinion. But I slightly tend to MSIX because inclusion into the Microsoft Store is a big plus (though I don't know how many users are actually using it). And even outside the Store, automatic updates can be implemented with an installer file which we can host on our server.

Let's take a look at the requirements listed in the initial post:

FOSS highly preferred

Not needed since everything comes from Microsoft directly.

Not reported as virus, ideally without requiring us to sign it

Signing needed, but I guess there's no solution available which works fine without signing. Maybe we could sign for free with SignPath, I'll ask them.

Allow upgrading older app versions

Should be possible (through Store or installer file).

Allow registering *.lpp[z] file extensions

Should be possible with the manifest file.

Somehow I don't like online installers (downloading the app on demand), so offline installation should be supported

MSIX contains the whole application.

CLI for headless & automated installation, uninstallation & update

Possible through Microsoft tools (e.g. PowerHell).

Toolkit installable in our Windows Docker image to allow building the installer on CI

Seems to work (https://github.com/LibrePCB/docker-librepcb-dev/pull/44).

Maybe support in-app updates (https://github.com/LibrePCB/LibrePCB/issues/648)?

Found some resources that this should be possible too.

---

Some links to MSIX:

• Packaging
• App installer file
• Windows App Certification Kit
• MSIX Limitations
• Comparison MSI vs MSIX

[ubruhin]

Seems this is not so trivial :-/

• MSIX/MSIXBUNDLE: Not an option at the moment:
  • Signing is mandatory, but SignPath currently is not able to provide free signing for projects using Azure Pipelines. They require some CI integration on their side to automatically verify that the files to sign are really built from the public sources (because they sign under their name and of course want to ensure it's not malware).
  • The sandboxing of MSIX causes a lot of new troubles. After a quick test to bundle LibrePCB in MSIX, I was able to install and start the application but no file open/save dialog worked and it crashed after a few seconds. I suspect this requires a lot of effort (and modifications in the source code) to get it working properly. Also I'm not sure if printer support should work in MSIX applications.
• MSI: I thought this would be the way to go then. But it seems the only (free) way to build MSI files is the WiX toolset, which is horrible not what I'm looking for:
  • Depends on .NET (~2GB larger Docker image!!!) and seems to be targeting mainly .NET applications as the terms NuGet, MSBuild and Visual Studio appear all the time when searching for WiX. As a C++ developer, I feel a lot of pain while reading their website.
  • The documentation is not even describing how to build an MSI installer with that tool. It's basically impossible to understand how to use this tool. Probably most users are just clicking some buttons in Visual Studio(?).
  • Since the direct usage of the tool is almost impossible, I tried using the CMake/CPack integration of WiX because (in theory) it allows to use this tool from a higher level perspective. Then it turned out that the CMake integration only works with a very old version of WiX, but this very old version failed to install on my Windows machine with a cryptic error message. So in the end after hours of trying, I was not able to build even a very simple MSI installer. Also it looks like the CMake integration is not really maintained, another reason for not using it.

So the only options left are *.exe installers, like we already have :sob: I think the main question left is which installer toolkit to use:

• NSIS (also has a CMake integration)
• Inno Setup
• Qt Installer Framework v4.x

Although we already use the Qt Installer Framework (v3), the new major version 4 seems to be heavily improved, especially regarding unattended install which is the biggest problem of our current installer. Also I'd then switch from online installers to offline installers to allow users installing older versions (and just to simplify things).

Will now evaluate these three options...

[ubruhin]

Status update:

• NSIS: Very powerful, but its scripting language is not intuitive at all, very difficult to work with.
• Qt Installer Framework: Not too bad, but contains nasty bugs so I stopped evaluating it.
• Inno Setup: Very intuitive and simple tool, but still very powerful with its scripting capability (in much nicer language than NSIS). Also very lightweight and easy to install in our CI Docker image.

So I think Inno Setup is the way to go. Here's a nightly build which can be tested:

https://download.librepcb.org/nightly_builds/1256-new-installer/librepcb-installer-nightly-windows-x86_64.exe

Silent install/upgrade (all options documented here):

librepcb-installer-nightly-windows-x86_64.exe /VERYSILENT /SUPPRESSMSGBOXES

Silent uninstall (all options documented here):

"C:\Program Files\LibrePCB\unins000.exe" /VERYSILENT /SUPPRESSMSGBOXES

The filename unins000.exe is theoretically not deterministic because the number gets incremented when installing another Inno Setup software into the same directory. However, I think you can ignore this edge-case and just call unins000.exe.

/cc @luzpaz @Dragon1573 in case you like to test this installer for usage in Chocolatey/winget, please don't publish this nightly build to users. I plan to make a new release very soon, this time with both the old installer and the new one (for a smooth migration).

[Dragon1573]

@ubruhin - The above nightly build can be successfully inspected by Komac v2.1.0 and installed via winget.exe version 1.7.10661.

[!NOTE]

We have to submit the manifest to microsoft/winget-pkgs for official tests.

There are both automated (by Azure Pipelines) and manual (by moderators) validation process. There may be some corner cases I have not tested yet. Official validation may check this installer further.

Screenshots

    

Manifests

- [LibrePCB.patch](https://github.com/LibrePCB/LibrePCB/files/14732121/LibrePCB.patch)

[ubruhin]

Awesome, thanks for testing! :tada:

Just two thoughts, not sure if relevant or not:

• The PackageVersion in the manifest is set to 1.2.5.6-nightly - shouldn't this be the LibrePCB version (currently 1.0.1-nightly)? However, the reported DisplayVersion is correct.
• For winget uninstall, is it really required to pass librepcb_is1 or would LibrePCB also work? Just because librepcb_is1 is not intuitive for users, but unfortunately Inno Setup registers LibrePCB under this name in the Registry and this can't be changed.

[Dragon1573]

• The PackageVersion in the manifest is set to 1.2.5.6-nightly - shouldn't this be the LibrePCB version (currently 1.0.1-nightly)? However, the reported DisplayVersion is correct.

From the above comments, I can't get the actual version number of this package. So I configured this to 1.2.5.6-nightly because number 1256 in the filename.

PackageVersion in manifest is configured manually by volunteers or contributors. They can be diverged with the DisplayVersionand link through AppsAndFeaturesEntries.

For most cases, volunteers or contributors will know the package version before they create the manifest. PackageVersion is the same as DisplayVersion.

• For winget uninstall, is it really required to pass librepcb_is1 or would LibrePCB also work? Just because librepcb_is1 is not intuitive for users, but unfortunately Inno Setup registers LibrePCB under this name in the Registry and this can't be changed.

I haven't test this yet. I can winget list LibrePCB to find the package, so it might by OK to just winget uninstall LibrePCB.

There's an -e switch (means "exact search") in my test, librepcb_is1 is required in this test case.

[ubruhin]

From the above comments, I can't get the actual version number of this package. So I configured this to 1.2.5.6-nightly because number 1256 in the filename.

Ah I see. But 1256 is just the number of this issue, not a version number :see_no_evil: Official releases will contain the version number in the filename (e.g. librepcb-installer-1.1.0-windows-x86_64.exe for version 1.1.0). Also the version number is added as a property on the installer *.exe, but I don't know if this information can be accessed by the winget tooling:

I haven't test this yet. I can winget list LibrePCB to find the package, so it might by OK to just winget uninstall LibrePCB. There's an -e switch (means "exact search") in my test, librepcb_is1 is required in this test case.

Alright, thanks for clarifying :+1:

[Dragon1573]

Official releases will contain the version number in the filename (e.g. librepcb-installer-1.1.0-windows-x86_64.exe for version 1.1.0).

For this case, I think volunteers or contributors may not be able to configure a wrong version number, except the bot account by Microsoft themselves (we found it behaves wierd in some corner cases).

Also the version number is added as a property on the installer *.exe, but I don't know if this information can be accessed by the winget tooling.

I think it can't. Not only Komac, but also wingetcreate.exe and YamlCreate.ps1 are not able to inspect the version of package. Version information of a manifest is manually-configured. I didn't download the installer file prior to the creation of the manifest, so I make this mistake 😥

[Dragon1573]

Excuse me @ubruhin, sorry to bother you again.

I see pull request #1340 is successfully merged and Qt6 based x86_64 build with InnoSetup packaged installer is finally released.

Do you interested in automating the release pipeline of The Microsoft community Windows Package Manager manifest repository via WinGet Releaser v2? It would be better maintaining a package by its owner instead of community volunteers.

However, enabling this pipeline requires at least one version of this package available in the repository. I can help creating the "very first" version of the manifest.

[ubruhin]

I see pull request https://github.com/LibrePCB/LibrePCB/pull/1340 is successfully merged and Qt6 based x86_64 build with InnoSetup packaged installer is finally released.

Wait wait wait, it's not released! :see_no_evil: Only nightly builds so far, no official release yet. So please don't publish it somewhere. Official releases will be available very soon and published at https://librepcb.org/download/.

Do you interested in automating the release pipeline of The Microsoft community Windows Package Manager manifest repository via WinGet Releaser v2? It would be better maintaining a package by its owner instead of community volunteers.

However, enabling this pipeline requires at least one version of this package available in the repository. I can help creating the "very first" version of the manifest.

Hm at the moment I don't see a need for a GitHub Action doing a release - we don't use GitHub Actions in this repository and in my experience for such a complex project it's better to do the (final step of) releasing manually. Releasing LibrePCB does not immediately mean releasing actual packages, because packages may require additional actions outside of this repository to get updated to a new version.

I agree about taking over packaging by the upstream maintainers would be nice. However, to be honest I'm already pretty busy with releasing all the other packages so I'm very happy about help of other people doing some of the packaging. Also I'm not familiar with Windows packages (don't use Windows for daily business) so the packaging & testing would be much easier for people familiar with these tools.

I'm not completely against taking it over, maybe I can look at it later. But at least for an initial version I'd be happy if someone else could do it. Of course I'm always available for any questions arising during packaging!

[ubruhin]

@Dragon1573 @luzpaz Now the new installer of the stable release 1.1.0 is available for inclusion in package managers:

https://download.librepcb.org/releases/1.1.0/librepcb-installer-1.1.0-windows-x86_64.exe

Can be silently installed/uninstalled as described in https://github.com/LibrePCB/LibrePCB/issues/1256#issuecomment-2015188804.

[Dragon1573]

Excuse me @ubruhin, is there only x86_64 packaged with InnoSetup? I see there's also x86 installer file in download center.

[dbrgn]

@Dragon1573 from the release notes 1.1.0:

The move to Qt6 forced us to drop support for Windows 7, Windows 8 and any 32-bit versions — upcoming releases will require at least Windows 10 64-bit. Since Windows 7 and 8 are already end-of-life for quite some time, it is highly recommended anyway to not use these systems anymore. But for now you can still use the Qt5 builds on them.

I assume that answers your question? 🙂 I think the x86 installer is just the old, deprecated one.

[Dragon1573]

@dbrgn - Thank you ❤️ x86 installer is not included in the manifest, users can only install x64 build by winget.exe

[ubruhin]

Yeah, the plan is that x86 releases won't be available anymore for upcoming releases, only x86_64 then.