Provide an .MSIX installation package.

[RokeJulianLockhart]

Although a Windows installer has been added (as #130 (comment) explains) it's quite retrograde. EXE has been replaced MSI, which was replaced by APPX, which has been replaced by MSIX. Anything except MSIX is not recommended by Microsoft, because it's not suitable for large-scale management (like via PowerShell and 1st-party deployment tools).

Even as a user (rather than an administrator) if you've ever installed an MSIX package, you'll know what a breeze it is – the GUI is always the same, because it uses the included MSIX installation tool from Microsoft.

Additional rationale is available at felixrieseberg/windows95#221 (comment).

[Loran425]

One roadblock to this is that MSIX packages appear to need to be code signed to run on a system not running in developer mode.
So $100-300/yr for the project to maintain signing capabilities depending on who you get the cert through.

[RokeJulianLockhart]

#241 (comment)

@Loran425, that is a pain. Might be worth following microsoft/msix-packaging#332 (comment), in case the decision there changes. However, are you certain about the lesser issue - that the certificate must be bound to the package on a non-developer mode OS installation? I would doubt that, considering that https://github.com/MicrosoftDocs/msix-docs/blob/730f4c2800902eb04de976929ff335ff2d24ea60/msix-src/package/sign-app-package-using-signtool.md#prerequisites doesn't mention it (and it would be logically strange).

Might be worth asking about at https://github.com/microsoft/msix-packaging/discussions/new?category=q-a.

[xarvex]

I'm not certain about the caveats around developer mode vs a typical install, I've honestly found it quite difficult to find information about MSIX at all. What does remain true is that code signing is required for typical usage, and unless you want to deal with having a user install your certificate (.crt) file you must go through a CA which creates a yearly cost.
One exception is distributing on the Microsoft Store, but relying on that means relying on that store being the only place of distribution, and thus is undesirable.
In that state of things, I do not see us packaging with MSIX. I could see an MSI (or APPX but I don't know much about it) in the near future, though, which is at least better than a lone EXE.

[RokeJulianLockhart]

#241 (comment)

@xarvex, the primary benefit of .MSIX for me is its ability to be easily managed by PowerShell via native commands, and its very standardized filesystem layout. No alternative provides those, except .APPX, but .APPX is a necessarily dead technology due to its unnecessarily sandboxed nature. .MSI doesn't provide any of these capabilities - it's solely an improvement over mere binaries because it abstracts the registry entries for the invocation and (un)installation .lnk files.

[yedpodtrzitko]

@RokeJulianLockhart it looks like you are the one who knows the most about MSIX, so feel free to open PR with Github Action for creating MSIX.

[RokeJulianLockhart]

#241 (comment)

@yedpodtrzitko, I do wish I did. Unfortunately, @xarvex was correct that there's not much documentation. If I can, I shall, but I've not even used GH Actions yet (I use GitLab mostly).

[xarvex]

For right now I'm going to leave this as a wontfix as we don't have the resources to explore CA signing. However, I will leave this issue open to continue tracking, it's not something I want to dismiss. Wishful thinking says maybe at some point there will be a change of heart at Microsoft about this.

I hope everyone can understand the stance taken.

[hi5a]

@xarvex @RokeJulianLockhart

It looks like signpath.io provides low-cost or free certificates to open source projects. It also looks like they are trusted by Rainmeter, vim for Windows, and Transmission.