RichardandClaude Opus 5
ab0a494f29
PolyTrader.App.csproj verwies per ProjectReference nach ..\..\LicenseLabrador\client-dotnet\... und baute damit nur auf einer Maschine, auf der das Schwester-Repo danebenliegt. Auf dem Zielland-System waere der Build fehlgeschlagen. Stattdessen liegt das SDK als versioniertes Paket in lib/nuget und wird ueber die NuGet.Config-Quelle "local" aufgeloest. Ein DLL-Verweis haette nicht gereicht: das Paket traegt die transitiven Abhaengigkeiten (BouncyCastle, ProtectedData, System.Text.Json) in seinen Metadaten. packageSourceMapping bindet LicenseLabrador.* fest an den lokalen Feed, damit ein gleichnamiges Paket auf nuget.org unseres nicht verdraengt (Dependency Confusion). Enthaelt ausserdem die bereits vorgemerkte Umbenennung LicenseDialog.Validate -> ValidateKey: der alte Name verdeckte ContainerControl.Validate() (CS0108), ein Aufruf ueber eine Form-Referenz haette einen Netzwerk-Call ausgeloest statt zu validieren. Build und Tests gruen (438 Tests). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lokaler NuGet-Feed (lib/nuget)
Hier liegen Pakete aus unseren eigenen Schwester-Projekten, die PolyTrader benutzt.
Warum ein Paket und keine Projektreferenz?
Ursprünglich verwies PolyTrader.App.csproj per ProjectReference direkt auf
..\..\LicenseLabrador\client-dotnet\.... Das koppelt die Repos hart: PolyTrader
baut dann nur noch auf einer Maschine, auf der LicenseLabrador 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 gewesen: das Paket trägt die transitiven Abhängigkeiten (BouncyCastle.Cryptography, Microsoft.Win32.Registry, System.Security.Cryptography.ProtectedData, System.Text.Json) in seinen Metadaten, eine nackte DLL nicht.
nuget.config bindet dieses Verzeichnis als Quelle local ein. Das
packageSourceMapping löst LicenseLabrador.* ausschließlich lokal auf, damit
ein gleichnamiges Paket auf nuget.org unsere Version nicht verdrängen kann
(Dependency Confusion).
Neue SDK-Version übernehmen
-
Im LicenseLabrador-Repo die
<Version>inclient-dotnet/LicenseLabrador.Client/LicenseLabrador.Client.csprojanheben (gleiche Version zweimal zu packen führt zu stillen Cache-Treffern — NuGet unterscheidet Pakete nur an der Versionsnummer). -
Paket bauen:
dotnet pack J:\Softwareprojekte\LicenseLabrador\client-dotnet\LicenseLabrador.Client\LicenseLabrador.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget -
In
PolyTrader.App.csprojdieVersionderPackageReferenceauf die neue Nummer setzen. -
Die alte
.nupkglöschen, damit klar bleibt, welche Fassung gilt. -
dotnet build+dotnet test— und die neue.nupkgmit committen.
Wichtig: Die Änderung am SDK gehört zuerst ins LicenseLabrador-Repo und wird dort committet. Dieses Verzeichnis ist nur die Auslieferung, nicht der Arbeitsort.