ajandClaude Opus 5.5
7fe4de4b6d
Publish-Windows.ps1 now packs the smoke-tested folder with the pinned vpk CLI (.config/dotnet-tools.json, 1.2.0 to match the Velopack package) into velopack/: Setup.exe, Portable.zip, the full nupkg, releases.win.json and RELEASES, checked for the full package and the portable layout and hashed into OpenNest.vX.Y.Z.velopack.sha256. The release workflow uploads them with the candidate. With no feed URL set, installed copies now check GitHub Releases (full releases only) instead of skipping update checks; a URL in Options still selects a self-hosted feed. Deploy-OpenNest.ps1 uses the pinned vpk. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.9 KiB
Desktop auto-update
The Windows desktop app (OpenNest.exe) can self-update via
Velopack: OpenNest.UpdaterService polls its update
source 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.
Where updates come from
By default an installed copy checks the public
GitHub Releases for full,
non-pre-release versions (GithubSource, unauthenticated: GitHub allows 60 API
requests per hour per IP address, ample for a 30-minute poll but shared by every
machine behind one address). Pre-releases are never offered.
To use a self-hosted feed instead, set Tools > Options > Auto-update feed URL
(OpenNest.Properties.Settings.UpdateFeedUrl, saved for the current Windows
user) to the feed's base URL (http://host:port) and restart. A self-hosted
feed URL is operator infrastructure and never belongs in source control; clearing
the field returns to GitHub Releases.
Velopack only applies updates to a Velopack installation (UpdateManager.IsInstalled):
a copy installed with OpenNest-win-Setup.exe or extracted from
OpenNest-win-Portable.zip. The plain OpenNest.vX.Y.Z.win-x64.zip and ordinary
build output contain no Update.exe and never auto-update; moving from one of
them to an updating copy is a one-time manual install.
Release packages
scripts/Publish-Windows.ps1 packs the same smoke-tested folder as the plain ZIP
with the vpk CLI pinned in .config/dotnet-tools.json (keep it equal to the
Velopack package version), into velopack/: OpenNest-win-Setup.exe,
OpenNest-win-Portable.zip, OpenNest-X.Y.Z-full.nupkg, releases.win.json
and RELEASES, with their hashes in OpenNest.vX.Y.Z.velopack.sha256. Installed
copies find an update through the releases.win.json and full package attached to
the newest full GitHub Release, so all five must be uploaded with it (see
releasing). Packages are full only; delta packages would
need the previous release's packages beside the output before vpk pack.
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 pinned vpk CLI, 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. Machines on a self-hosted feed only see
versions pushed to that feed.