j.foucher
dc72e7eee6
Bug rapporté : après update client vers 1.0.9, un opérateur ne voyait qu'UNE
ligne alors que le manifest en contenait deux au même numéro. Root cause :
mon refactor v1.0.8 keyait les rows par folder name résolu via
GetInstallFolderName(). Sur les manifests existants (où l'opérateur n'avait
pas encore migré vers un installFolderTemplate distinct par channel), les
deux entries résolvent au même dossier « PROSERVE v1.5.4.32 » — le dico
TryAdd droppait la seconde silencieusement (juste un log warn).
Fix : row identity passe sur l'Id de l'entrée manifest (unique par entry,
auto-généré server-side depuis longtemps via generate_entry_id()). Le folder
name reste utilisé pour le matching installed ↔ remote quand l'entryId
manque (installs d'avant v1.0.8 qui n'ont pas encore été re-installés).
Bénéfices :
• Les deux entries s'affichent MÊME si elles partagent un
installFolderTemplate. L'install guard côté client bloquera l'écrasement
au moment de l'install avec le message clair habituel.
• Migration transparente : les installs existants continuent d'être matchés
par folder name tant qu'ils n'ont pas d'EntryId dans leur meta. Au
ré-install, le meta reçoit son EntryId et le matching devient canonique.
Détails :
── Model ─────────────────────────────────────────────────────────────
• InstalledVersion : nouveau champ optionnel EntryId (default null pour la
rétro-compat des call sites existants).
── Registry ──────────────────────────────────────────────────────────
• Scan() populate EntryId via TryReadEntryId(dir). null si le fichier meta
n'existe pas ou si la clé est absente (install antérieur à v1.0.8).
── MainViewModel.RebuildList ─────────────────────────────────────────
• remoteByRowKey : keyé par Id de l'entry (fallback folder name si le
manifest est très vieux et n'a pas d'id).
• installedByRowKey : keyé par EntryId lu du meta ; fallback = folder name
; fallback ultime = héritage de l'Id d'un remote match si un install
legacy pointe vers un remote qui, lui, a un Id.
• Tri VersionOrder : lookup version + isBeta par rowKey via deux dicos
rawByRowKey/installedByRowKey (au lieu de folder name).
── VersionRowViewModel ───────────────────────────────────────────────
• RowKey : priorité (Remote.Id → Installed.EntryId → folder name → Version).
Aligné avec la logique RebuildList pour que les lookups par RowKey
trouvent la row correcte.
Bump : 1.0.9 → 1.0.10 (fix critique du refactor v1.0.8).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PS_Launcher
Launcher Windows pour l'application UE5 PROSERVE : gère plusieurs versions cohabitantes, téléchargement et installation de nouvelles versions depuis un serveur, validation de license, release notes.
Composants
src/— Solution C# / .NET 8 / WPF (Visual Studio 2022 + SDK .NET 8 requis)PSLauncher.App: UI WPF (style Epic Games Launcher)PSLauncher.Core: services (Manifest, Download, Install, Process…)PSLauncher.Models: DTOs partagés
server/— Code serveur PHP 8 (à déployer souswww/PS_Launcher/sur OVH mutualisé)
Démarrage rapide (dev)
dotnet build PS_Launcher.sln
dotnet run --project src/PSLauncher.App
Pour produire un binaire autonome distribuable (un seul .exe ~70 Mo) :
dotnet publish src/PSLauncher.App -c Release
# Sortie : src/PSLauncher.App/bin/Release/net8.0-windows/win-x64/publish/PSLauncher.exe
Configuration locale
Le launcher écrit sa config dans %LocalAppData%\PSLauncher\config.json au premier lancement.
Édite serverBaseUrl pour pointer vers ton serveur :
{
"serverBaseUrl": "https://ton-domaine.com/PS_Launcher/api",
"installRoot": "C:\\ASTERION\\GIT\\PS_Launcher\\ASTERION_VR"
}
État (roadmap)
- ✅ v0.1 — Scan + lancement de versions installées
- ✅ v0.2 — Manifest distant, download ZIP, install cohabitante, release notes Markdown
- ⏳ v0.3 — Reprise (HTTP Range), retry Polly, state.json
- ⏳ v0.4 — License (MySQL + Ed25519 + DPAPI)
- ⏳ v0.5 — Settings, suppression manuelle versions, toasts
- ⏳ v1.0 — Auto-update launcher, MSI installer
Voir le plan détaillé pour la roadmap complète.
Licence / interne
Repo interne ASTERION. Ne pas distribuer.