Seit Deploymentcenter 2.4 liegt die Release-Ablage hinter HTTP-Basic-Auth mit
dem Lizenzschluessel als Zugangsdatum. Ohne ihn antwortet jeder Paketabruf mit
401. Predictalytics hat noch kein Release veroeffentlicht; nach UPGRADE.md
16.1 entsteht der Schutz fuer ein Produkt mit dem ersten Upload, der erste
ausgelieferte Build muss die Zugangsdaten also bereits mitbringen.
- DcUpdateService reicht licenseKey und platform (PlatformId.Current) an
CheckForUpdateAsync und LaunchUpdateAgent weiter. Fehlt der Schluessel am
Aufruf, greift LicenseClient.TryGetCachedKey - damit ist der Headless-Pfad
mit abgedeckt.
- LaunchAgent startet ohne Lizenzschluessel gar nicht erst. Sonst schliesst
sich die Anwendung, der Agent laeuft in einen 401, und zurueck bleibt eine
geschlossene App ohne Update.
- restartPath und waitForCurrentProcess werden gesetzt: der Agent wartet auf
das Ende dieses Prozesses, statt auf noch gesperrte Assemblies zu schreiben,
und startet die Anwendung danach wieder. Ein null-restartPath ist dafuer
nicht brauchbar - das SDK ersetzt ihn durch denselben ProcessPath -, beim
Start ueber "dotnet App.dll" wird deshalb der Apphost aufgeloest.
- result.Unauthorized wird vor dem "ist aktuell"-Zweig behandelt. Bei 401
setzt das SDK weder Error noch UpdateAvailable; die Pruefung meldete bisher
"aktuell", waehrend in Wirklichkeit keine Updates mehr ankamen.
- Version zentral in Directory.Build.props, damit Hosting und Shell nicht
auseinanderlaufen.
- run.sh setzt unter Linux das beim Entpacken verlorene Ausfuehrungsbit.
.gitattributes haelt Shell-Skripte auf LF: mit core.autocrlf=true traegt die
Arbeitskopie sonst CRLF, und CopyToPublishDirectory nimmt genau die ins
Linux-Paket - dort scheitert der Start an "bad interpreter".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
