Implement the scripting and packing systems for a exe/msi installer

[halgari]

User story

**As a user, I'd like to have a Windows native .exe installer instead of manually unpacking archives

**I want to install the app without understanding how to open .zip files

**So that I can install the app easier

Requirements

Implement a scripted installer, should allow the user to set the install path, default to an install path, and add the app to the user's start menu

Non-requirements

Linux/OSX support or any other OS. Other OSes can use archives.

Design

Ping @insomnious and see if we can just copy what Vortex does. We don't need anything special here, so we should be able to copy all of this and use it in the app

[insomnious]

Vortex uses NSIS as part of Electron builder so you prob want to take a look at something like https://github.com/Squirrel, it's popular and cross-platform

[erri120]

For Linux, we'd want an AppImage and/or a flatpack image plus a PKGBUILD file for the AUR. This is something me and @Sewer56 can take a look at since we're both running Arch btw ™️.

[Sewer56]

Vortex uses NSIS as part of Electron builder so you prob want to take a look at something like https://github.com/Squirrel, it's popular and cross-platform

Noticed during meeting.

This is tied to #376 , and #376 specifies

Install the app to a chosen directory/location

If this must hold true, we cannot use Squirrel because Squirrel's opinionated approach forces an install to AppData on Windows.

[erri120]

My findings so far:

Linux

Can be completely handled by PupNet. See this example workflow definition, and you can find some build artifacts in this workflow.

Packaging for Linux is super easy and straightforward, unlike what follows next…

Windows

Squirrel

The project has been essentially been abandoned. Furthermore, the C# integration is severely outdated and resolves packages that use the .NET Framework. I haven't been able to get this to work at all, and given the fact that the project is dead, I haven't pursuit this any further.

Inno Setup using PupNet

PupNet also supports creating an Inno Setup for Windows. Similar to the Linux packaging, this worked flawlessly, and you can try this out here.

I've been unable to get the signing tool to work, but the issue is being tracked at kuiperzone/PupNet-Deploy#25. I might be able to sign the executable manually, but I'd like to wait until the linked issue is resolved.

Inno Setup only handles the installation, it doesn't handle updating. If we want to use this installer, we'd have to roll our own update detection system.

The setup process and only marginally be configured, as PupNet generates an Inno Setup file for us.

MSIX

MSIX is the "latest" package format for Windows applications. It requires a special WAP Project and raw MSBuild invocations, but I've managed to make it work and you can see the result here.

A few things to note with MSIX: as detailed by the Microsoft docs, MSIX packages are distributed by either the Microsoft Store or the Web. Since we won't publish on the MS Store, the Web deployment method is the only option. A "web" deployment essentially just means having a simple website that hosts these two files:

• The actual package to install (this is a .appx file)
• A installer manifest that tells Windows how to install the package (.appinstaller)

This manifest also contains the version number, and Windows can periodically check if the app needs to be updated. Updating is done automatically, but can be turned off during the build process. I don't know if the user can manually disable the auto-updating feature, but given that this is Windows, I don't think that's the case.

Releasing a new version is as simple as building a new .appx and .appinstaller file and uploading it to the hosted website.

This deployment method works by having a link on a website that the user can click. The link looks like this:

ms-appinstaller:?source=https://example.com/MyApp.appinstaller

This will launch the app installer built into Windows, which will download the installer manifest and then the actual package. All of this is tightly integrated into Windows, but the documentation is pretty bad and focused around deploying to the MS Store. It's also not made for non-standard .NET applications, the docs are focused around Win UI, MAUI and UWP applications instead.

Additionally, all MSIX packages have to be signed. This process is actually pretty straight forward, and I was able to sign the example release using a fake certificated that can easily be replaced with a real one.

The assets used for MSIX packages can be customized greatly. Everything from logos to icons to splash screens can be configured.

ClickOnce

ClickOnce was made specifically for the .NET Framework, and was update for .NET Core and beyond. It is similar to MSIX, but less integrated into the Operating System itself. Once again, you can find an example workflow and artifacts here.

ClickOnce works by creating three files:

• A launcher executable named Launcher.exe
• An application manifest (.manifest)
• A deployment manifest (.application)

The launcher will run the main application after doing an update check. The only viable deployment method available is, once again, "Web" deployment. This is similar to MSIX where you host the manifests on a site, which the launcher will contact on launch to determine if an update is available.

ClickOnce applications can easily be signed and are much easier to set up than MSIX packages. Although ClickOnce has been updated to be used for .NET Core applications, it's still very much made for .NET Framework applications. The manifests have the .NET Framework listed as a dependency, instead of .NET Core.

WiX

The WiX Toolset offers the most customizations available out of all options listed. The docs are extensive, but lack real examples. WiX can be used to output .exe setup bundles, .msi installation packages and more. It offers extensions for detecting and installing dependencies, fixing firewall rules and more. The installer can be fully customized, we can even create our own in .NET.

Similarly to Inno Setups, we'd need our own update mechanism if we want to this type of installer. The benefit of Inno Setups and installers created using WiX, is that deployment is very straightforward, since they only output an .exe or .msi file.

Custom

There is always the option to roll a custom installer and launcher. This would be the easiest and most straightforward option, as it allows us to fully customize the installation and update process.

[halgari]

A few things we'll need to consider in future milestones:

• Updating the application - no one-stop shop exists for updating .NET apps that works across all platforms and "Stores", so whatever happens we'll likely need to roll our own tech here
• We can't update a running app, hence the talk of "launchers" which are startup shims which check for updates on startup and then launch the main app, the main app can then update the launcher
• Whatever we choose we likely want to provide support updating the datamodel and configs, data migration

Of all the choices above, Inno and WiX seem like the only viable options, and Inno is much simpler, while having the same tradeoffs as WiX. All this in mind, I think we can move forward with Inno/Pupnet. For this initial ticket we'll just configure installing of the app, not updating or migration. We'll schedule those in later milestones/tickets.

[Greg-Nexus]

A few things we'll need to consider in future milestones:

• Updating the application - no one-stop shop exists for updating .NET apps that works across all platforms and "Stores", so whatever happens we'll likely need to roll our own tech here
• We can't update a running app, hence the talk of "launchers" which are startup shims which check for updates on startup and then launch the main app, the main app can then update the launcher
• Whatever we choose we likely want to provide support updating the datamodel and configs, data migration

Of all the choices above, Inno and WiX seem like the only viable options, and Inno is much simpler, while having the same tradeoffs as WiX. All this in mind, I think we can move forward with Inno/Pupnet. For this initial ticket we'll just configure installing of the app, not updating or migration. We'll schedule those in later milestones/tickets.

I think we should consider updating in the next milestone, which incidentally releases a new "version" to users.