aj
98a046a112
Remove a private part reference from the lead-in notes, fix the Options and New menu paths, say that release ZIPs never auto-update, describe current Cincinnati CL ordering, clamp validation coverage and empty-plate saving, list every built-in engine, and drop internal decision labels.
1.8 KiB
Desktop auto-update
The Windows desktop app (OpenNest.exe) can self-update via
Velopack: OpenNest.UpdaterService polls a static
file feed every 30 minutes, downloads a newer release in the background, and
only restarts to apply it after the user confirms (a clickable status-bar
item appears once a download finishes). It never force-restarts; an open,
unsaved nest is never discarded automatically.
Configuring the feed
The feed URL is saved for the current Windows user
(OpenNest.Properties.Settings.UpdateFeedUrl), set from Tools > Options >
Auto-update feed URL. It is blank by default, which disables update checks
entirely — this is intentional: the feed URL is operator infrastructure, not
something that belongs in source control, so no default ships in the repo.
Enter a feed's base URL (http://host:port) and restart the app to pick it
up.
Velopack only applies updates to an installed copy (UpdateManager.IsInstalled):
one installed with the Setup.exe that Deploy-OpenNest.ps1 produces. The ZIPs on
GitHub Releases and ordinary build output are not Velopack installations and never
auto-update, even with a feed URL configured.
Hosting a feed
Any static file server that can serve a vpk pack output directory works.
scripts/Deploy-OpenNest.ps1 builds a self-contained win-x64 publish,
packs it with the vpk CLI (dotnet tool install -g vpk), and scps the
result to a directory you provide:
./scripts/Deploy-OpenNest.ps1 -FeedHost <host> -FeedUser <user> -RemoteDataDir <path>
Bump <Version> in OpenNest/OpenNest.csproj before each run. This is
independent of the GitHub release process and of
Publish-Windows.ps1 — the latter always overrides <Version> via
-p:Version, so the two don't conflict.