top of page

Fünf Lehren aus der Migration auf .net 5/6 (=.net Core) / Five lessons from migrating to .net 5/6 (=.net Core)

29. Okt. 2021

.net expert Patrick Smacchia

Tipps und Hinweise zur Migration vom "klassischen" .net-Framework nach .net 5/6 (=Core) / Tips and hints for migrating from the "classic" .net framework to .net 5/6 (=Core)

Deutsch

English


Deutsch

Der .net-Fachautor Patrick Smacchia hat folgende fünf Lehren aus der Migration auf .net 5/6 (also .net Core) publiziert


#1 net Standard ist nicht tot.

Anstatt mehrere Redistributables zu haben – eine für jedes Betriebssystem – haben wir eine einzige beibehalten.

Ein einziges Redistributables zu haben, macht die Dinge für die Benutzer einfacher und für uns einfacher zu warten.

Wir haben nicht direkt auf .net 5 migriert.

Stattdessen werden 99 Prozent des migrierten Codes jetzt gegen .net Standard 2.0 kompiliert.

Nur die Assembly .\net5.0\NDepend.Console.MultiOS.dll wird gegen .net 5.0 kompiliert.

Diese leichtgewichtige ausführbare Assembly enthält lediglich eine Klasse zum Aufrufen der gesamten Analyse-/Berichtsverarbeitung, die in .net Standard 2.0-Assemblys implementiert ist.

Die Aufgabe besteht lediglich darin, dotnet.exe das Booten der .net 5.0-Laufzeit zu ermöglichen.

Siehe auch https://www.officium-inservio.com/news/netstandardfuture


#2 Erwarten Sie "Schmerzpunkte".

Microsoft hat mit .net Standard und .net Core sicherlich hervorragende Arbeit geleistet, indem es die meisten APIs, die häufig im "klassischen" .net Framework verwendet werden, vorgestellt und unterstützt hat.

Erwarten Sie jedoch einige nicht unterstützte APIs, die Workarounds und Refactoring-"Kopfschmerzen" verursachen werden.


#3 Werkzeuge wie "NDepend" können helfen, die meisten Migrationsprobleme zu vermeiden.


#4 Die Pflege der Code-Wartbarkeit kann zu einer Frage des Überlebens werden.

Die beiden wichtigsten Prinzipien sind Mehrschichtige Architektur und ein hoher Testabdeckungsgrad.


#5 Bibliotheken von Drittanbietern, auf die verwiesen wird, müssen modular, leichtgewichtig und quelloffen sein.

Erfahrene Entwickler wissen, dass jede referenzierte Bibliothek eine potenzielle Belastung für die Zukunft darstellt.

Jeder Verweis ist ein Kompromiss zwischen dem Aufwand für die eigene Arbeit + Wartung und dem Aufwand für die Integration der Bibliothek + Aufwand für die Aktualisierung und das Testen neuer Versionen + Menge der Probleme, die sie in der Zukunft verursachen kann.


English

The .net specialist author Patrick Smacchia has published the following five lessons from the migration to .net 5/6 (i.e. .net core).


#1 net standard is not dead.

Instead of having multiple redistributables - one for each operating system - we kept a single one.

Having a single redistributable makes things easier for users and easier for us to maintain.

We did not migrate directly to .net 5.

Instead, 99 percent of migrated code is now compiled against .net Standard 2.0.

Only assembly .\net5.0\NDepend.Console.MultiOS.dll is compiled against .net 5.0.

This lightweight executable assembly contains only one class to invoke all analysis/reporting processing implemented in .net Standard 2.0 assemblies.

Its job is just to allow dotnet.exe to boot the .net 5.0 runtime.

See also https://www.officium-inservio.com/news/netstandardfuture


#2 Expect situations of "pain".

Microsoft has no doubt done an excellent job with .net Standard and .net Core by introducing and supporting most of the APIs commonly used in the "classic" .net Framework.

However, expect some unsupported APIs that will cause workarounds and refactoring "headaches".


#3 Tools like "NDepend" can help avoid most migration problems.


#4 Maintaining code maintainability can become a matter of survival.

The two most important principles are multi-layer architecture and high test coverage.


#5 Third-party libraries referenced must be modular, lightweight and open source.

Experienced developers know that each referenced library represents a potential burden for the future.

Each reference is a trade-off between the effort to do your own work + maintenance and the effort to integrate the library + the effort to update and test new versions + the amount of problems it may cause in the future.



bottom of page