Simplifies the rename done in ce3979d : PS_Launcher.exe is the only
name. Removes the dual-path lookup in LauncherSelfUpdater, the
duplicated taskkill blocks in the .bat scripts, the legacy patterns
in .gitignore, and the explanatory comments about the migration.
Cleaner code, single source of truth for the binary name.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Aligns the executable name with the repo / product naming. Backward-
compatible: existing installs that have PSLauncher.exe on disk continue
to work — the self-updater overwrites the file at the running .exe path
without renaming, so the historical filename persists on those machines.
Changes
- AssemblyName : PSLauncher → PS_Launcher (both App and Updater csproj)
- Inno Setup : MyAppExeName, MyUpdaterExeName, OutputBaseFilename all
now use PS_Launcher prefix
- LauncherSelfUpdater : looks for PS_Launcher.Updater.exe first, falls
back to legacy PSLauncher.Updater.exe so old installs keep updating
- Build scripts (build-launcher / build-updater / build-installer /
build-all) : taskkill both legacy AND new names; output paths printed
with new names
- .gitignore : added PS_Launcher.exe / PS_Launcher.Updater.exe /
PS_Launcher-*.exe patterns alongside the legacy ones; also ignored
the WebView2 user-data folder and Office ~$ lock files
- Server admin/launcher.php : URL pattern now generates
PS_Launcher-{ver}.exe ; SignManifest's existing tolerant glob
*{ver}*.exe still matches both names
- Versions bumped to 0.14.0 (App + Updater + installer .iss)
Migration story for clients
- Brand-new install via PS_Launcher-Setup-0.14.0.exe → PS_Launcher.exe
on disk
- Existing install (PSLauncher.exe) auto-updates to v0.14 → file stays
named PSLauncher.exe but contains v0.14 code; self-updater fallback
ensures future updates keep working
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Single-instance
---------------
Two PSLauncher.exe instances ran in parallel during the user's last
release build, locking the repo-root copy and breaking the publish.
Two-layer protection:
1. App.xaml.cs uses a Global\ named Mutex (UUID-based key) created at
OnStartup. If the mutex is already held, the second instance
PostMessages a registered Windows message (PSLAUNCHER_BRING_TO_FRONT)
to HWND_BROADCAST and Shutdown()s immediately.
2. MainWindow hooks WndProc via SourceInitialized + HwndSource.AddHook;
when it sees the broadcast, it restores from minimized, calls
ShowWindow(SW_RESTORE) + Activate() + SetForegroundWindow so the
already-running instance pops to the user's foreground.
Net result: clicking the launcher icon a second time pops the existing
window instead of starting a duplicate process.
Tolerant build pipeline
-----------------------
- Both csproj post-publish copy targets now have
ContinueOnError="WarnAndContinue". A locked PSLauncher.exe at the
repo root no longer fails the entire publish — the binary still
exists in bin\Release\...\publish\ and the user gets a warning
instead of an error.
- All four .bat scripts (build-launcher / build-updater / build-all /
build-installer) now run `taskkill /F /IM PSLauncher.exe /T` and the
same for PSLauncher.Updater.exe before the publish step. This
defensively closes any stray instance left behind by previous tests
so the build pipeline is clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
build-launcher.bat: publishes PSLauncher.App only (Release single-file).
build-updater.bat: publishes PSLauncher.Updater only.
build-all.bat: both, sequentially, fast-fail on the first error.
All three pause at the end so a double-click from Explorer shows the
result before the window closes. The existing build-installer.bat
(launcher + updater + Inno Setup .exe) stays as the full release
pipeline.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
