# 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 1. Im LicenseLabrador-Repo die `` in `client-dotnet/LicenseLabrador.Client/LicenseLabrador.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\LicenseLabrador\client-dotnet\LicenseLabrador.Client\LicenseLabrador.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget ``` 3. In `PolyTrader.App.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 LicenseLabrador-Repo und wird dort committet. Dieses Verzeichnis ist nur die Auslieferung, nicht der Arbeitsort.