Microsoft.NET.Sdk.WindowsDesktop emits NETSDK1100 when a Windows-
targeting project is built from a non-Windows host. Setting
EnableWindowsTargeting=true opts in to the cross-compile path, which
works on Linux as long as the WindowsDesktop SDK files are present.
On glados they were copied from a Windows .NET 8 SDK archive into
/usr/lib/dotnet/sdk/8.0.126/Sdks/Microsoft.NET.Sdk.WindowsDesktop/
and /usr/lib/dotnet/packs/Microsoft.WindowsDesktop.App.Ref/. This is
a one-time setup per Linux host -- see the bridge-claude memory note.
No-op on Windows hosts (the flag has no effect when the SDK is native).
Both PC builds and glados builds now produce the same output.
So existing 0.4.8 installs see the upgrade banner in their current
launcher after the next deploy. The actual session-refresh code change
landed in the previous commit (DoLaunchAsync pre-launch refresh).
Adds Services/SelfUpdateService.cs implementing the Chrome-style pattern:
1. Download new exe to "<current>.new"
2. Rename running exe to "<current>.old" (NTFS allows MoveFile on a
running exe -- it resolves processes by handle, not by path)
3. Rename ".new" to canonical path
4. Spawn the new exe with our argv
5. Environment.Exit(0)
6. Next start of the new exe runs CleanupAfterUpdate() in App.OFIC()
which deletes the leftover ".old"
UI: the existing "Download" banner button is now "Install update". Click
runs the self-update flow with a percent/MB progress label; any failure
(network, AV write-block, dir not writable) falls back to opening the
URL in the browser so users always have a path forward.
Bumps to 0.4.7. Also fixes a stale fallback URL that pointed at
sijbers.uk/pack/... -- now correctly points at bns.sijbers.uk/launcher/.
Matt
Matt Sijbers