MSI installer

[mwu-tow]

It has been raised that switching our installer technology to MSI format might be beneficial. MSI offers standardization, customization for administration, group policy integrations, rollback/repair functionality, and is widely used by vendors. Supporting this format might be a requirement for some enterprise customers.

We've already had some experiments with generating MSI from the electron-builder output. The result were not satisfactory, as the generated packages still were liable to the long paths issues. And the long paths handling issues were the reason why we've started investigating alternatives to NSIS in the first place.

---

It has been suggested that issues with MSI could be avoided by using WiX Toolset directly rather than relying on the electron-builder. Electron-builder uses an outdated version of WiX Toolset (7 years old) which is missing recent fixes (and some long path issues indeed were fixed). The WiX Toolset is a free software that can be used to create MSI installer.

I did some experiments with WiX Toolset and found it to be low-level and not very easy to use. The tutorials are outdated or assume using WiX with the Visual Studio plugin and MSBuild integration. Still, WiX is not really bound to VS and has proper support for CLI usage. WiX uses XML configuration files to describe the installer. This description is low level and verbose, WiX does not provide convenient abstractions for common installer tasks.

Unfortuantely, it seems that even using the latest (v5) WiX Toolset does not solve the long paths issues. The installer can be built from a package in a long location (provided that the paths are prefixed with the verbatim \\?\), but the installer fails at runtime when extracting files that would end up in long paths. And in this case even the verbatim prefix does not help (it seems to be explicitly rejected by the installer with complaint "could no access network location").

---

MSI can be shipped with custom extensions or even run our code during the installation. This could be used to work around the long paths issues, however this is non-trivial and in general feels like working against the MSI design. (Also, possibly, we lose the benefits of the MSI format by doing so.)

As such, I don't think that continuing the WiX experiments is worth it. If we want standard MSI installer, we should restructure our package to avoid long paths. Then we could use the electron-builder to generate the MSI. Otherwise, keeping the custom installer makes sense, at least until we have a better understanding of the specific requirements for the enterprise customers.

It should be noted that MSI can be built using the electron-builder almost out-of-the-box with --electron-target msi (one trivial tweak in the electron-builder configuration is needed to fix the validation).

---

Currently in my Enso installation the longest path is C:\Users\mwurb\AppData\Local\Programs\enso\resources\enso\dist\2024.1.1-nightly.2024.5.15\lib\Standard\Visualization\2024.1.1-nightly.2024.5.15\.enso\cache\suggestions\2024.1.1-nightly.2024.5.15\Standard\Visualization.suggestions.meta. This is 234 characters and worryingly close to the limit. Adding more nested files or longer version suffix could push it over the edge. There is certainly potential for package layout optimization.

---

To sum up: there's little reason to use WiX Toolset directly. We will end up facing similar problems as with electron-builder-generated MSI — and the latter is readily available.