Packaging (Windows): installer component selection + Windows Service

[jozef2svrcek]

Windows half of the cross-platform packaging split (Linux shipped in #65). Split out from #66.

Goal

The NSIS installer offers component selection — Client / Server / Both (default Both):

• Client — the GUI + chess-db.exe on PATH.
• Server — a Windows Service (LPDOServer) running chess-db serve, data under C:\ProgramData\LPDO (mirrors the Linux /var/lib/lpdo system model).

Approach (planned)

• LPDO_DATA_DIR env override in chess-db (required — Windows dirs::home_dir() ignores $HOME, so the Linux redirect can't work). Linux-testable, lands first.
• WinSW service wrapper (chess-db serve isn't SCM-aware; bare sc create → error 1053; the windows-service crate is Windows-only Rust). LocalSystem for v1.
• Custom Tauri NSIS template + installerHooks (installMode: perMachine): Components page; PREINSTALL stops the service (exe-lock/upgrade), POSTINSTALL adds PATH + creates C:\ProgramData\LPDO + registers/starts the service; PREUNINSTALL stops+removes the service and PATH but keeps the data (mirrors Linux postrm).
• CI: fetch WinSW on the windows-2022 leg; tauri-action --bundles nsis picks up the template/hooks. Dry-run via workflow_dispatch + throwaway tag.

Validation

CI compiles the NSIS installer; real install/service/ACL/PATH behaviour is verified by a manual Windows test (no Linux dev access to Windows).

Related

#60/#65 (Linux precedent), #58 (CLI proxy so a Client-only install talks to a local/remote server).

[jozef2svrcek]

Status update (2026-06-22): iteration 1 shipped; component selection deferred

Iteration 1 — DONE (merged #70): Windows NSIS .exe installs a WinSW-supervised system service (LPDOServer → chess-db serve), data under C:\ProgramData\LPDO (LPDO_DATA_DIR), keep-DB-on-uninstall. Fresh-install FATAL and the "delete app data" checkbox were fixed and the maintainer verified it on Windows. This is what ships for now.

Component selection (Client / Server / CLI) — DEFERRED. Postponed until there's a concrete need (e.g. an enterprise / thin-client ask), to avoid churn now. This issue stays open to track it.

Decision rationale (for the revisit)

We evaluated adding the selection page to the current NSIS .exe vs switching to WiX .msi:

• Both require forking a version-coupled Tauri installer template that drifts on Tauri upgrades — neither is fork-free.
• NSIS fork = 977 lines + must vendor the EnVar plugin (Tauri's NSIS doesn't bundle it) for PATH + imperative sc/WinSW hook scripts.
• WiX/MSI fork = 381 lines, and the hard parts are declarative natives: <ServiceInstall>/<ServiceControl>, <Environment> (PATH), MajorUpgrade, Permanent="yes" keep-data. Also MDM/GPO-friendly.
• Recommended path when revisited: MSI-only (drop the .exe; one installer, no "which one?"). Trade-offs: one-time WiX authoring + blind CI dry-run iterations, and a one-time .exe→.msi uninstall+reinstall for existing users (their C:\ProgramData\LPDO\chess.db is preserved and reused).

Preserved MSI/WiX design (so it isn't lost)

• Fork main.wxs (bundle.windows.wix.template) with minimal edits: WixUI_InstallDir → WixUI_FeatureTree; replace the stock MainProgram block with three top-level Level="1" features GUI / CLI / Server (all default-checked). Pin to the tauri-bundler version in Cargo.lock; re-diff on each Tauri bump.
• CLI feature → windows/fragments/cli.wxs: a component with <Environment Name="PATH" Value="[INSTALLDIR]" Part="last" System="yes"/> + a KeyPath <RegistryValue>. (Tauri's stock "PATH Environment Variable" feature is misnamed — it has no <Environment> element, so PATH is NOT free.)
• Server feature → windows/fragments/server.wxs: install WinSW (LPDOServer.exe+.xml) via authored <File> under INSTALLDIR\windows\service\ so the component can own <ServiceInstall>/<ServiceControl Start="install" Stop="both" Remove="both">; C:\ProgramData\LPDO(+\logs) as Permanent="yes" <CreateFolder/> components (kept on uninstall). Server shares the chess-db sidecar component (present even if CLI unchecked). Highest-risk unknown: whether <File Source> resolves from Tauri's WiX working dir — fallback is keep WinSW as a resource + a registry-keyed ServiceControl-by-name component.
• Config: tauri.windows.conf.json → bundle.windows.wix with a fixed new upgradeCode GUID + template + fragmentPaths. Do NOT use componentRefs/featureRefs (they sink into Tauri's hidden, unselectable External feature). CI: windows-2022 leg --bundles nsis → msi (Tauri auto-fetches the WiX toolset; keep the WinSW fetch).