feat(windows): add native MSI installer (WPB-5221)

[adamlow-wire]

WPB-5221 [Desktop] Windows installer

Summary

Adds a native, per-machine Windows MSI installer for enterprise deployment through MDM and software-management systems.

The existing Squirrel EXE path remains available. MSI installations deliberately do not run the application-managed Squirrel updater; enterprises update them by deploying a newer MSI with the same permanent upgrade code.

Jira: WPB-5221

What changed

• adds an electron-builder MSI build target with stable product-family upgrade codes
• installs per-machine under Program Files and supports quiet msiexec deployment
• preserves desktop and Start menu shortcuts plus the wire: protocol registration
• adds branded installer UI and an embedded Wire banner
• prevents the Squirrel updater from starting when an MSI installation has no Update.exe
• signs and verifies the versioned MSI in the Windows release pipeline
• deploys the version-matched MSI artifact to S3
• documents MDM deployment, upgrades, detection, migration risks, and release acceptance criteria

Validation

• build/deployment unit tests: 23 passing
• updater compatibility tests: 2 passing
• TypeScript type checks and test compilation pass
• ESLint, Prettier, Groovy syntax, and git diff --check pass
• native x64 MSI builds successfully
• MSI tables inspected for per-machine scope, identity, upgrades, shortcuts, protocol registration, launch condition, and branding
• quiet administrative extraction with msiexec /a ... /qn succeeds

Release checks still required

• production certificate signing and timestamp verification in Windows CI
• ICE/WiX validation on the signed release artifact
• fresh install, repair, uninstall, and N-to-N+1 upgrade as SYSTEM on supported Windows versions
• migration testing with an existing per-user Squirrel installation
• validation in the target MDM tenant, including detection and rollback
• update the external Windows smoke-test job and download-page consumer before MSI promotion

Security

• no new network endpoints, credentials, or privilege-escalation mechanism
• installer scope is intentionally per-machine and therefore requires administrative deployment authority
• production signing is configured to use SHA-256, timestamping, fail-fast signing, and verification of all signatures

[screendriver]

This prevents installation on Windows 10. Windows Installer reports VersionNT = 603 on Windows 10 for compatibility so VersionNT >= 1000 evaluates to false. We need a Windows 10+ launch condition here, for example based on WindowsBuild.

See also the official Microsoft documentation: https://learn.microsoft.com/en-us/troubleshoot/windows-client/application-management/versionnt-value-for-windows-10-server

[adamlow-wire]

Good catch. Fixed in 736e10b1 with the condition “Installed OR (VersionNT >= 603 AND WindowsBuild >= 10240)”, plus a regression test. Apparently Windows 10 is 6.3 when Windows Installer asks.

[screendriver]

I think we should have the MSI to be created alongside the currently created .exe installer. This replaces the existing Squirrel production build in Wrapper_Windows_Production and there is no separate production Squirrel job in Jenkins, so after this change we would stop producing new Wire-Setup.exe / .nupkg releases.

[adamlow-wire]

Agreed. Fixed in a3be121c: the job now builds Squirrel and MSI from the same signed app, signs/verifies/archives both, and deploys them to separate paths. Squirrel packaging failures are fatal too, so the MSI cannot politely hide a broken existing release.

[screendriver]

I may be missing this, but I don't see a way for the MSI deployment to configure the backend URL. The according ticket explicitly calls this out so that enterprise deployments don't need to create init.json or set an environment variable manually.

Is this handled somewhere else or is the MSI configuration for the backend URL still missing?

[adamlow-wire]

This was missing. Fixed in b595c110: the MSI accepts WIRE_WEBAPP_URL, stores it machine-wide, retains it across upgrades, and supports replacement or clearing. The app gives it precedence over --env and init.json, and validates it as credential-free HTTPS.