Ich hatte den ServicePack 31.2 installiert, der bei mir nicht wie gewünscht funktioniert. Jetzt hatte ich gehofft, dass ich einfach die Nuget-Version zurückdrehe auf
Leider zieht er sich aber nicht die DLLs, die über Nuget bereitgestellt werden, sondern greift die DLLs aus C:\Program Files (x86)\combit\LL31\Redistribution\x64 zurück.
Das heißt, dass ich jetzt wieder den 31.1 ServicePack installieren muss, um aus der Nummer rauszukommen.
Gibt es dafür eine andere Lösung? Weil ich müsste doch ein ServicePack testen können, ohne dass ich mir gleich meine ganze Maschine verseuche.
bei der Verwendung des NuGets werden in der Regel immer die Module aus der lokalen Installation in das bin-Directory beim Kompilieren verwendet. Somit kann die NuGet-Version und die Version der nativen Module aus der Installation auseinander laufen - kann sogar sein, dass es dazu eine Warnung beim Kompilieren in VS geben müsste.
Wenn vorhanden, mal versuchen das SP 31.001 drüber zu installieren. Alternativ kann man in der Enterprise Edition auch das zugehörigen Enterprise NuGet verwendet: Dort werden die Module NICHT aus der lokalen Installation bezogen, sondern sind Teil des NuGet packages - siehe auch NuGet Package Unterstützung.
Danke für den Link! Darin wurde meine Befürchtung nochmal bestätigt:
Die List & Label NuGet Packages enthalten nur die ausgewählten .NET Assemblies. Während der Erstellung Ihres Projekts werden die unmanaged Module von List & Label aus dem Installationsverzeichnis “..\Redistribution\” in den Ausgabeordner der Anwendung kopiert und sind nicht Teil der NuGet Packages. Bitte beachten Sie daher bei der Aktualisierung der NuGet Packages, dass auch das entsprechende List & Label Service Pack installiert werden muss. Auf diese Weise passen dann die Versionen der unmanaged Bibliotheken zu den .NET Assemblies der NuGet Packages. In .NET-Systemarchitektur finden Sie weitere Details zu den .NET Assemblies und den unmanaged Modulen.
Das heißt für uns, dass wir zwar verschiedene LL Versionen verwenden können, aber nicht verschiedene SPs in unterschiedlichen Projekten. Wir können also erst auf einen höheren SP umstellen, wenn sichergestellt ist, das der in SP in allen Projekten läuft. Unter Umständen müssen wir dann mehrere Monate warten, bis der nächste SP mit dem Fix veröffentlicht wurde und das entsprechende NuGet Package dafür zur Verfügung steht. Das verzögert unsere Entwicklung immer kolossal.
Wir hätten zwar die Enterprise-Version, aber konnten nicht auf diese Nugets umstellen, weil das irgendwelche anderen Probleme in unserer Build-Pipeline hervorgerufen hatte, die nicht zu lösen waren.
Wir hätten zwar die Enterprise-Version, aber konnten nicht auf diese Nugets umstellen, weil das irgendwelche anderen Probleme in unserer Build-Pipeline hervorgerufen hatte, die nicht zu lösen waren.
Uns würde interessieren, welche Probleme in der Build-Pipeline vorliegen und deswegen nicht das Enterprise-Package verwendet werden kann? Das würden wir gerne verstehen, um die Anforderung zukünftig erfüllen zu können. Denn das Enterprise-Packge erfüllt sehr gut die Verwendung von unterschiedlichen Versionen auf einfachem Weg.
Wir werden es nochmal prüfen und versuchen auf die Enterprise-Nugets umzustellen. Wenn es größere Probleme geben sollten, würde ich mich demnächst wieder hier melden.
