Kürzlich bin ich über ein Assembly-Resolve Problem gestolpert, das am Ende leicht zu lösen war, aber der Weg dorthin war bemerkenswert unintuitiv…
Für ein .net core Projekt entschied ich mich NET6 zu verwenden, da dies eine LTS (long-term-service) Version ist – weiters entschied ich mich für framework-dependency, um die Setup-Größe klein zu halten. Alle Nuget-Pakete wurden stets in neuester Version hinzugeladen (oft auch v7.0) – und das ging sehr lange gut… 🙂
Solange, bis ich irgendwann folgendes Paket benötigte:
System.Security.Cryptography.ProtectedData
Denn ab da bekam ich plötzlich eine Exception beim App-Start, weil die ProtectedData assembly nicht geladen werden konnte – sie war aber da und der Pfad stimmte auch!
Die Lösung
Irgendwann später kam ich drauf, dass unter dem namespace System.Security.Cryptography.* mehrere Assemblies vereint sind, aber nur eine davon (*.ProtectedData.dll) landete in meinem Publish-Ordner. An dieser Stelle schwante mir schon, dass „meine“ ProtectedData v7.0 die restlichen System.Security.Cryptography.* Assemblies evtl. ebenfalls als v7.0 aus der Runtime nachladen möchte (die es dort aber nur als v6.0 gibt) und probierte einen Rücksprung auf v6.0.1. Dabei handelte ich mir aber ein Dependency-Problem mit den System.Directory.* Assemblies ein, die ja ebenfalls v7.0 waren.
=> Also bekamen alle Nuget-Pakete (System.Security.Cryptography.* UND System.Directory.*) ein Downgrade auf v6.0.x. Und die App lief sofort wieder einwandfrei – nach nur ein paar Klicks in der Nuget-Paketverwaltung. 🙂
Offene Fragen
Das warf dann fast zwangsläufig Fragen nach der Best-Practice im Umgang mit den Nuget-Paket-Version auf, die unter anderem hier auch schon von anderen diskutiert wurden: https://stackoverflow.com/questions/74781983/net-6-project-in-visual-studio-offers-update-nuget-packages-to-7-0-0
Und da stehen dann Sätze wie: it’s typically just „try or error“, oder: Yep, there is no rule – Yay!
Now, I’m even more curious!
Mich hat es dann irgendwann interessiert, ob mir mit den neuesten v6.0.x Assemblies etwas fehlt, immerhin suggeriert die Versionsnummer 7.0 einen gewaltigen Fortschritt, oder? 🙂
Also am Beispiel System.DirectoryServices.dll in den Versionen 6.0.0/1 und 7.0.0/1 mit ILSpy vier Assemblies decompiliert und mit WinMerge verglichen… und ich kann sagen die 6.0.1 und die 7.0.0/1 sind fast komplett identisch! Man verliert also keine Funktionalität (zumindest nicht bei den DirectoryServices).
Fazit
Für mich persönlich stelle ich nun erstmal die Regel auf, bei einer NET6 App auch möglichst bei den nuget Paketen 6.0.x zu bleiben.
Schreibe einen Kommentar