Laden...

Logic-DLL universell verwendbar machen (.net 4.8 und .net 6.0)

Erstellt von Christoph K. vor einem Jahr Letzter Beitrag vor einem Jahr 879 Views
Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor einem Jahr
Logic-DLL universell verwendbar machen (.net 4.8 und .net 6.0)

Hallo zusammen,

ich betreue ein ziemlich großes Projekt, welches aus mehreren einzelnen Projekten besteht, die teilweise als Anwendung laufen, teilweise als ASP MVC Projekt und teilweise auf der Konsole.
Alle Projekte bedienen sich für die Kernfunktionen aus einer Logic-DLL.

Die Projekte sind zurzeit alle mit .net 4.8 umgesetzt.

Bei neuen Projekten wollen wir im Team nun auf .net 6.0 setzen, welches ja nicht mehr kompatibel zu .net 4.8 ist. Wir möchten aber bei den neuen Projekten im Gesamtprojekt ebenfalls auf die Logic-DLL zurückgreifen.

Ist es hier der richtige Weg, die Logic-DLL in .net-Standard 2.0 zu konvertieren?

VG

2.079 Beiträge seit 2012
vor einem Jahr

Dafür ist/war es gedacht.

.NET Standard

Achte aber darauf, dass ihr die 4.8 Projekte auch noch auf 6 zieht.
.NET Standard wird nicht mehr weiterentwickelt, ist also nur eine Übergangslösung.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

16.832 Beiträge seit 2008
vor einem Jahr

Siehe Erklärung in [FAQ] Das .NET Ökosystem - .NET, .NET Core, .NET Standard, NuGet und Co

Ist es hier der richtige Weg, die Logic-DLL in .net-Standard 2.0 zu konvertieren?

Der "richtige Weg" würde direkt heissen: Monolith* aufbrechen und .NET 6 verwenden.
.NET Standard ist End of Life, der Zweck wurde erfüllt - ist also nur ein Übergangszweck.
Wirst nicht drum herum kommen irgendwann (zeitnah) ganz auf .NET 6 zu wechseln.

*Single DLL ist nicht das, was die Idee hinter DLLs ist - egal welche Technologie.
Packt man alles in eine riesen DLL endet das i.d.R. in enormen Runtime und Dependency Issues.; gilt daher als großer Anti Pattern.
Es macht eine Aufgabe, wie Du sie nun hast, in den aller meisten Fällen (wenn man von "großen Anwendungen" spricht), enorm schwer, komplex, teilweise unmöglich.
Funktioniert das dann bei Dir doch leicht dann hast Du a) enormes Glück oder b) doch eher keine so "große Anwendung" mit entsprechenden Abhängigkeiten 😉
Nicht zu wechseln mit einem DLL Merge am Ende.

PS: "ziemlich großes Projekt" ist eine relative Angabe, die für jede:n eine andere Bedeutung hat.
Auch die "Menge" an Projekten in Solutions hat da wenig Aussagekraft.