[FEATURE] New Installer + Updater

[ad-mca-mk]

Which component(s) does this affect?

• Full Dashboard
• Lite
• SQL collection scripts
• Installer
• Documentation

Problem Statement

Users need to download new versions today. There should be an automatic update.

Proposed Solution

We use this package https://github.com/squirrel/squirrel.windows for all apps that need to be installed, and it works very stable. Slack, Spotify and many others are using it. It supports digital signing as well.

This is an idea for you to consider, and I can help out if you'd like a PR.
Not going to spend time if you are no interested to take it there now or want to do it yourself.

Use Case

Just use the app and always be on the latest version.

Alternatives Considered

No response

Additional Context

No response

[erikdarlingdata]

Thanks for the fantastic suggestion! Squirrel.Windows is a great fit for this — the fact that Slack and Spotify rely on it says a lot about its stability.

Auto-update would eliminate the biggest friction point in the upgrade process right now (downloading a new zip, extracting, re-importing connections and data). We'll take it from here and look into integrating this.

Appreciate the offer to help — we'll reach out if we need input on the implementation.

[erikdarlingdata]

Implementation Plan

After researching Squirrel.Windows, Clowd.Squirrel, and Velopack, we're going with Velopack — it's the modern successor to Squirrel, purpose-built for .NET 8, supports GitHub Releases as an update source out of the box, and handles delta updates, code signing verification, and rollback.

Phase 1: Data Directory Migration (prerequisite)

Both Velopack and Squirrel completely replace the app directory on update — there's no "skip folder" mechanism. Lite currently stores everything alongside the exe (config/, monitor.duckdb, archive/, logs/). This must move to %LOCALAPPDATA%\PerformanceMonitorLite\.

New structure:

%LOCALAPPDATA%\PerformanceMonitorLite\
├── current\              ← app binaries (managed by Velopack)
├── config\               ← servers.json, settings.json, schedules, ignored waits
├── data\monitor.duckdb   ← DuckDB database
├── data\archive\         ← parquet archive files
└── logs\                 ← application logs

Migration on first launch: If the new location is empty but the old exe-relative location has data, automatically copy everything over. Existing users upgrade seamlessly.

Changes:

• App.xaml.cs: Change DataDirectory, ConfigDirectory, DatabasePath, ArchiveDirectory to point at %LOCALAPPDATA%
• ServerManager, SettingsWindow, DuckDbInitializer, ArchiveService, CollectionBackgroundService: All receive paths from App.xaml.cs already, so they should just work
• First-run migration logic in App.OnStartup

Phase 2: Velopack Integration

App startup:

// Early in App.OnStartup
VelopackApp.Build()
    .OnFirstRun(v => { MigrateFromOldInstall(); })
    .OnBeforeUninstallFastCallback(v => { /* optional cleanup */ })
    .Run();

Update check (on startup + periodic):

var mgr = new UpdateManager(new GitHubSource(
    "https://github.com/erikdarlingdata/PerformanceMonitor"));

var newVersion = await mgr.CheckForUpdatesAsync();
if (newVersion != null)
{
    // Show tray notification: "v2.4.0 available — click to update"
    // User clicks → download in background with progress
    await mgr.DownloadUpdatesAsync(newVersion, progress);
    // Prompt: "Update downloaded. Restart now?"
    mgr.ApplyUpdatesAndRestart(newVersion);
}

Behavior:

• Check on startup (30-second delay so it doesn't slow launch)
• Check every 24 hours while running
• Non-blocking tray notification when an update is available
• User controls when to download and when to restart
• Delta updates — only downloads what changed between versions

NuGet: Add Velopack package to PerformanceMonitorLite.csproj

Phase 3: Build Pipeline

GitHub Actions changes:

• Add vpk pack step after dotnet publish for Lite
• Produces: Setup.exe (initial installer), full .nupkg, delta .nupkg, releases.json
• Upload all artifacts to GitHub Releases
• Setup.exe replaces the current zip for first-time installs
• Existing users get auto-update going forward

Artifacts per release:

• PerformanceMonitorLite-Setup.exe — one-click installer (new users)
• PerformanceMonitorLite-2.4.0-full.nupkg — full update package
• PerformanceMonitorLite-2.4.0-delta.nupkg — delta from previous version
• releases.json — update manifest
• Dashboard and Installer zips remain unchanged (no auto-update for those initially)

Phase 4: Dashboard Auto-Update (follow-up)

Dashboard already stores data in %APPDATA% so it's ready for Velopack without the data migration step. Same integration pattern as Lite.

What this eliminates

Once auto-update is in place:

• No more zip downloads and manual extraction
• No more Import Data / Import Connections for upgrades (data stays in place)
• Users are always on the latest version
• Delta updates minimize download size
• SignPath signing integrates with Velopack's signature verification

Scope estimate

• Phase 1 (data migration): Medium — touches path initialization and needs first-run migration logic
• Phase 2 (Velopack integration): Small — the API is straightforward
• Phase 3 (build pipeline): Medium — new packaging step in GitHub Actions
• Phase 4 (Dashboard): Small — data location already correct

Phases 1-3 can ship together as one release. Phase 4 is a follow-up.

[ad-mca-mk]

Great Plan. I have only heard off Velopack - seems like the thing you need, and much better integration with GitHub.

[erikdarlingdata]

@ad-mca-mk thanks so much for suggesting it, really. It's so obvious, but my brain just never went there.

I kept trying to figure out how to make new version releases louder, but this is way smarter.

[erikdarlingdata]

Progress Update

Completed

• Version check on startup added to all 4 apps (CLI installer, GUI installer, Dashboard, Lite)
• Velopack NuGet package (0.0.1298) added to Dashboard
• VelopackApp.Build().Run() startup hook added
• Local vpk pack tested successfully — produces Setup.exe (93MB), full nupkg (91MB), portable zip, and release manifests

Remaining

1. Move VelopackApp.Build().Run() to a custom Main() entry point (Velopack warns about OnStartup placement)
2. Wire UpdateManager with GitHubSource into Dashboard's existing update check
3. Update GitHub Actions build pipeline: self-contained publish → vpk pack → vpk upload github
4. End-to-end test: release with Velopack packages → Dashboard detects → downloads → applies → restarts
5. Repeat for Lite (requires data directory migration to %LOCALAPPDATA% first)