The 0.4.10 build was already deployed (replacing the broken 0.4.9 that
shipped without launcher-config.json embedded). This commit just makes
the repo match what's live so a future 'git status' isn't dirty.
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).
Microsoft access tokens have a ~1 hour TTL. The launcher cached the
MSession once at sign-in and re-used it on every Play click, so leaving
the launcher open for >1 hour and then hitting Play sent stale
credentials to MC -- Mojang's session check on the server then rejected
the join with "Invalid session".
Fix: in DoLaunchAsync, before assembling the MC launch command, call
_auth.TryAuthenticateSilentlyAsync(). XboxAuthNet's silent flow uses
the cached refresh token (~14 day TTL) to mint a fresh access token
transparently. On success ApplySession swaps in the new MSession and
we launch with valid credentials. On failure (refresh token also
stale) the launcher prompts the player to sign in again -- they keep
the launcher open, hit Sign In, no MC restart needed.
No new dependencies, no UI change beyond the brief "Refreshing
session..." status line, no perf cost beyond the ~500ms HTTP roundtrip
to Microsoft each launch.
Bump the launcher version in launcher/ModpackLauncher.csproj before
publishing so old launcher installs see the upgrade banner.
Bake each file's "side" (client / server / both) into manifest.json at
build time so both the launcher and the server filter deterministically
and offline. This replaces the launcher's previous "download everything"
default and lets the server short-circuit its runtime Modrinth lookup
when a file already has an authoritative tag.
Schema:
- ManifestFile.Side: "client" | "server" | "both" (null = "both" for
backward compat with manifests pre-dating this field)
- Files marked "both" omit the field entirely to keep the JSON tight
Code changes:
- launcher Manifest.cs + ManifestSyncService: filter out "server" files
in both the prune+download path and FindMissingFiles
- server Manifest.cs + ManifestSync: drop "client" files outright; only
fall back to the existing runtime Modrinth lookup for files with no
explicit side (legacy/un-tagged mods stay protected)
- server LockedMod: side field propagates into manifest at build time
- scripts/Build-Pack.ps1: propagate side from lockfile to manifest
- scripts/Bootstrap-Sides.ps1: one-off populator; queries Modrinth's
client_side/server_side per project, conservatively marks restricted
only when one side is "unsupported", leaves ambiguous cases as "both"
- pack/pack.lock.json: bootstrap-populated sides (3 client, 5 server,
rest both); CurseForge mods default to "both" pending manual review;
version bumped 0.9.3 -> 0.10.0 since clients must re-sync
Compatibility:
- Old launcher + new manifest: ignores unknown "side", downloads all
- New launcher + old manifest: side null -> "both", installs all
- Old server + new manifest: same -- runtime Modrinth lookup still works
- New server + old manifest: side null -> runtime lookup, same behaviour
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