RichardandClaude Opus 5
5ccd4f5f4e
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>