j.foucher
c20d4603a2
Bug rapporté : après avoir itéré des builds beta 1.5.4.30 / .31 / .32
(isBeta=true, 4-digit), publier 1.5.4 (isBeta=false, 3-digit) comme
release finale ne rendait PAS 1.5.4 la version "courante" côté launcher.
Deux cas d'échec :
1. Client canSeeBetas=true (opérateur/testeur) : les deux visibles,
1.5.4.32 restait en tête du tri (SemVer strict : 1.5.4 == 1.5.4.0
< 1.5.4.32).
2. Client canSeeBetas=false avec 1.5.4.32 déjà installé : l'install
locale n'est jamais filtrée par isBeta, donc restait en tête aussi.
Root cause : SemVer.CompareTo() traite le 4ᵉ digit comme un patch
post-release (documenté ainsi dans SemVer.cs pour supporter les itérations
de test 1.5.4.13 alignées sur leur release stable 1.5.4). Cette sémantique
casse quand le 4-digit est en fait un "pré-release" beta destiné à être
supplanté par la 3-digit finale.
Fix : nouveau helper VersionOrder.Compare(versionA, isBetaA, versionB,
isBetaB) qui ajoute une règle par-dessus SemVer :
Au MÊME préfixe 3-digit (X.Y.Z égaux) ET statut beta différent, la
version isBeta=false l'emporte, indépendamment du 4ᵉ digit.
Hors ce cas exact (préfixes 3-digit différents, ou même statut beta des
deux côtés) : SemVer strict, aucune régression sur les scénarios existants
(1.5.4.30 beta < 1.5.4.32 beta reste vrai, 1.5.4 < 1.5.5 reste vrai, etc.).
Application aux deux hotspots :
• UpdateChecker.CheckAsync — tri par VersionOrder au lieu de SemVer,
ET pour la comparaison isNewer, retrouve l'isBeta d'origine de l'install
locale via lookup dans manifest.Versions (si l'entrée existe encore).
• MainViewModel.RebuildList — tri combiné installé/remote via VersionOrder.
L'isBeta est lookupé dans le RAW remote (avant le filtre canSeeBetas),
sinon un client sans droits beta ayant installé une beta perdrait
l'info et retomberait sur SemVer strict.
Migration : aucune côté data. Les versions publiées comme beta restent
identifiées par leur flag isBeta ; le launcher les considère automatiquement
comme pré-release dès qu'une non-beta au même préfixe 3-digit apparaît
dans le manifest. Publish 1.5.4 (isBeta=false) → devient la version featured
même sur les postes ayant 1.5.4.32 installé.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PS_Launcher — Installeur
Génère un setup Windows (PSLauncher-Setup-{version}.exe) qui distribue
le launcher principal + son updater dans Program Files\ASTERION VR\PSLauncher\.
Pré-requis
- .NET 8 SDK (déjà installé pour build le projet)
- Inno Setup 6.x — https://jrsoftware.org/isdl.php (gratuit, ~6 Mo)
Build en une commande
Depuis la racine du repo :
powershell -ExecutionPolicy Bypass -File installer\build-installer.ps1
Ça enchaîne :
dotnet publish src/PSLauncher.App -c Release→PSLauncher.exe(~77 Mo)dotnet publish src/PSLauncher.Updater -c Release→PSLauncher.Updater.exe(~10 Mo)ISCC PSLauncher.iss→installer/output/PSLauncher-Setup-X.Y.Z.exe
Le fichier final fait ~80 Mo (compression ultra Inno + binaires self-contained).
Distribution
Tu balances un seul .exe au client :
- Il lance, choisit français/anglais, clique Suivant×3, c'est installé.
- Raccourci bureau + menu Démarrer créés.
- Désinstallation propre via Programmes et fonctionnalités.
Le cache utilisateur (%LocalAppData%\PSLauncher\config.json, logs, downloads partiels)
n'est pas touché par l'install/désinstall — la license et les paramètres survivent.
Mise à jour du launcher
Le launcher se met à jour seul via PSLauncher.Updater.exe (cf. flow auto-update).
Le client n'a pas besoin de rejouer l'installeur sauf changement majeur (TFM, déps).
Bumper la version
Avant de rebuild un installeur :
src/PSLauncher.App/PSLauncher.App.csproj→<Version>X.Y.Z</Version>(et AssemblyVersion / FileVersion)installer/PSLauncher.iss→#define MyAppVersion "X.Y.Z"installer/build-installer.ps1
Côté serveur, mets aussi à jour manifest/versions.json section launcher avec la
nouvelle version + URL de download du nouveau PSLauncher.exe (via le backoffice
ou édition manuelle, puis php tools/sign-manifest.php).
Code-signing (optionnel)
Pour éviter le warning SmartScreen "éditeur inconnu", il faut signer
PSLauncher.exe, PSLauncher.Updater.exe et PSLauncher-Setup-X.Y.Z.exe avec
un certificat Authenticode (OV ~250 €/an, EV ~400 €/an, ou gratuit via SignPath
pour OSS). Hors-scope du script actuel.