Framework-Konflikt mit DocumentFormat.OpenXml

Deutschsprachiges Forum
1

Guten Morgen,

wir verwenden List&Label 29 mit einer .Net8.0 Applikation. Das nuget-Paket liefert dazu korrekterweise die combit.ListLabel29 dll im Format NETCoreApp v8.0. Dann allerdings ist die combit.ListLabel29.Export.x64 dll nur als Net Framework 4.8 dll verfügbar, dementsprechend wird DocumentFormat.OpenXml mit Net Framework 4.6 referenziert.

Das kollidiert allerdings mit einer Funktionalität unserer Anwendung welche ClosedXML für Excel-Dateien benötigt, ebenfalls DocumentFormat.OpenXml referenziert, und hier kommt DocumentFormat.OpenXml dann als NETCoreApp 6.0 heraus - was von MSBuild bevorzugt wird.

Das Ergebnis ist daß L&L keinen Export mehr für Formate machen kann welche DocumentFormat.OpenXml brauchen, da die Framework-DLL die NetCore DLL nicht laden kann.

Wird es die Abhängigkeiten der combit.ListLablelxx.dll auch mal im NETCore-Format geben? Und wie gehen wir jetzt weiter vor?

LG F. Leeber

2

Oh und bevor ich es vergesse das betrifft auch die SQLite-Abhängigkeit, die würde bei uns auch potentiell einen Konflikt verursachen, aber unsere Reports haben offenbar da keinen Bedarf :wink:

3

Hallo,

wie ich schon sehen konnte wurde bereits ein entsprechender Support-Case bei uns für die Anforderung erstellt.

Wir sind gerade dabei die Rahmenbedingungen zu klären, in welcher Abhängigkeit die DocumentFormat.OpenXML-Assembly im List & Label Kontext (siehe combit.ListLabel.Export.[x86/x64].dll) verwendet werden kann, so dass Ihre Anwendung mit einer anderen referenzierten Version von DocumentFormat.OpenXML weiterhin ausgeführt wird. Abschließend werden wir die Ergebnisse des Support-Case hier mitteilen.

Vielen Dank,
Daniel Stein

4

Vielen Dank! Ich hab das dann nur als Case gemeldet weil der Eintrag hier grau erschien und ich nicht sicher war wann der überhaupt sichtbar wird :wink:

lg

5

Derzeit setzt List & Label mit .NET Framework 4 OpenXML in der Version 2.2.0 voraus. Diese Voraussetzung kollidiert mit der .NET-Bibliothek ClosedXML. Selbst wenn wir OpenXML auf die derzeit aktuelle Version 3.0.2 anheben würden, gäbe es aufgrund diverser Breaking Changes Probleme:

Folgender Workaround ist möglich:

  • Alles, was mit List & Label zu tun hat, sowie alles, was mit ClosedXML zu tun hat, in ein eigenes Projekt bzw. eine eigene Assembly auslagern.
  • Projekt/Assembly in den bin-Ordner legen, z.B. in das Unterverzeichnis “Reporting”.
  • Dann die Dateien aus diesem Verzeichnis mit AssemblyResolve aus der “Haupt”-Anwendung laden.

Dieser Workaround ist ab List & Label 30 nicht mehr notwendig. Für die kommende Version wird eine Anpassung vorgenommen, die diese Abhängigkeit umgeht.