Files

T

RichardandClaude Opus 5 bf8048b82a Fruehjahrsputz: WinForms ausgebaut (P11/L5), LicenseLabrador abgeloest (D-6)

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>

2026-08-22 10:58:43 +02:00

2.6 KiB

Raw Blame History

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

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).

Paket bauen:

dotnet pack J:\Softwareprojekte\Deploymentcenter\client-dotnet\Deploymentcenter.Client\Deploymentcenter.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget

In src/PolyTrader.Core/PolyTrader.Core.csproj die Version der PackageReference auf die neue Nummer setzen.
Die alte .nupkg löschen, damit klar bleibt, welche Fassung gilt.
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.

2.6 KiB Raw Blame History

Lokaler NuGet-Feed (lib/nuget)

Warum ein Paket und keine Projektreferenz?

Neue SDK-Version übernehmen

2.6 KiB

Raw Blame History

Lokaler NuGet-Feed (`lib/nuget`)