RichardandClaude Opus 5
bf8048b82a
Das Repo enthaelt ab jetzt ausschliesslich plattformneutralen Code. Build gruen (0 Fehler), 476 Tests gruen, Linux-Publish der Avalonia-App verifiziert. Rueckfallebene ist der Tag winforms-final, der jetzt auch auf dem Server liegt. WinForms endgueltig ausgebaut (P11/L5): - PolyTrader.App.csproj aus PolyTraderSharp.sln genommen und geloescht - Ui/, Models/, Licensing/, services/, Properties/, Resources/icons/, Program.cs, favicon.ico entfernt - rund 4.500 LOC generierter Designer-Code - Root-appsettings.json entfernt: exaktes Duplikat der Avalonia-Kopie, die die App tatsaechlich liest. Zwei Dateien mit gleichem Inhalt laufen frueher oder spaeter auseinander. - Kein net10.0-windows mehr im Repo; Build-Warnungen von 23 auf 15 gesunken (die CS0169 aus den Designer-Resten sind weg) PNG-Symbole gerettet statt geloescht: Die Avalonia-App band sie per ..\..\Resources\*.png aus dem Repo-Root ein und haette sie mitverloren. Sie liegen jetzt in src/PolyTrader.App.Avalonia/Assets/, wo sie hingehoeren. Der avares-Pfad "Assets/<datei>.png" bleibt unveraendert - in der gebauten Assembly nachgeprueft. LicenseLabrador abgeloest (D-6): - LicenseLabrador.Client aus lib/nuget entfernt, Quellen-Mapping in NuGet.Config auf Deploymentcenter.* reduziert, lib/nuget/README.md neu - Bewusste Abweichung vom Plan: die Watchdog*-Felder in ServerSettings bleiben. D-1 hat sie auf die Deploymentcenter-API umgewidmet statt sie zu ersetzen; sie werden aktiv benutzt. Die Planzeile stammte aus der Zeit davor. Weitere Altlasten: - agentspace/ (30 Dateien: WinForms-Designer-Patcher, fix_mongo.py nach der MySQL-Migration, tmp/test/scratch-Skripte) entfernt - Ideen-fuer-Mittwoch.txt entfernt - Inhalt ist laengst umgesetzt - tote .gitignore-Regel fuer agentspace/antigravity/ entfernt - lokal entfernt (nicht versioniert): MongoDB/-Exporte, data.db, .bak-Datei Dokumentation nachgezogen: - ANALYSE-Linux-Portierung.md auf Revision 6, P11/L5 als erledigt - LEITFADEN: Abschnitt B vollstaendig aufgeloest, A5 prueft ab jetzt gegen einen Worktree des Tags statt gegen den Arbeitsbaum - UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md als ABGELOEST gekennzeichnet, D-6 im Deploymentcenter-Plan auf den Iststand gezogen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
50 lines
2.6 KiB
Markdown
50 lines
2.6 KiB
Markdown
# Lokaler NuGet-Feed (`lib/nuget`)
|
|
|
|
Hier liegen Pakete aus unseren **eigenen Schwester-Projekten**, die PolyTrader benutzt.
|
|
Aktuell genau eines: `Deploymentcenter.Client` (Lizenz, Watchdog, Fehler-Reporting, Updates).
|
|
|
|
> Bis zum 22.08.2026 lag hier zusätzlich `LicenseLabrador.Client`. Das Paket ist mit dem
|
|
> Ausbau der WinForms-Anwendung entfernt worden — Lizenzprüfung und Heartbeat laufen
|
|
> vollständig über das Deploymentcenter (siehe
|
|
> `docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md`, Schnitt D-6).
|
|
> Der letzte Stand mit LicenseLabrador liegt im Git-Tag `winforms-final`.
|
|
|
|
## Warum ein Paket und keine Projektreferenz?
|
|
|
|
Eine `ProjectReference` direkt nach `..\..\Deploymentcenter\client-dotnet\...` würde die
|
|
Repos hart koppeln: PolyTrader baute dann nur noch auf einer Maschine, auf der das
|
|
Schwester-Repo zufällig daneben liegt — ein Build-Server oder das Zielland-System hätte
|
|
den Build nicht mehr übersetzen können.
|
|
|
|
**Die Projekte bleiben eigenständig.** Deshalb wird das SDK als versioniertes
|
|
NuGet-Paket in dieses Verzeichnis gelegt und mitversioniert. Ein reiner DLL-Verweis
|
|
wäre nicht ausreichend: das Paket trägt die transitiven Abhängigkeiten in seinen
|
|
Metadaten, eine nackte DLL nicht. Zusätzlich liefert es unter `build/` die
|
|
`Deploymentcenter.BuildInfo.targets` mit, die beim Bauen die Klasse
|
|
`PolyTrader.Core.BuildInfo` (Version, Git-Commit, Build-Datum) erzeugt.
|
|
|
|
`NuGet.Config` bindet dieses Verzeichnis als Quelle `local` ein. Das
|
|
`packageSourceMapping` löst `Deploymentcenter.*` **ausschließlich** lokal auf, damit
|
|
ein gleichnamiges Paket auf nuget.org unsere Version nicht verdrängen kann
|
|
(Dependency Confusion).
|
|
|
|
## Neue SDK-Version übernehmen
|
|
|
|
1. Im Deploymentcenter-Repo die `<Version>` in
|
|
`client-dotnet/Deploymentcenter.Client/Deploymentcenter.Client.csproj` **anheben**
|
|
(gleiche Version zweimal zu packen führt zu stillen Cache-Treffern — NuGet
|
|
unterscheidet Pakete nur an der Versionsnummer).
|
|
2. Paket bauen:
|
|
|
|
```
|
|
dotnet pack J:\Softwareprojekte\Deploymentcenter\client-dotnet\Deploymentcenter.Client\Deploymentcenter.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget
|
|
```
|
|
|
|
3. In `src/PolyTrader.Core/PolyTrader.Core.csproj` die `Version` der `PackageReference`
|
|
auf die neue Nummer setzen.
|
|
4. Die alte `.nupkg` löschen, damit klar bleibt, welche Fassung gilt.
|
|
5. `dotnet build` + `dotnet test` — und die neue `.nupkg` mit committen.
|
|
|
|
**Wichtig:** Die Änderung am SDK gehört zuerst ins Deploymentcenter-Repo und wird dort
|
|
committet. Dieses Verzeichnis ist nur die Auslieferung, nicht der Arbeitsort.
|