Software wandelt sich kontinuierlich. Es gibt historisch gesehen eine Vielzahl von verschiedenen .NET Versionen. Die Strategie von Microsoft für “One .NET”, die Zusammenlegung von .NET Framework und .NET Core, ist erfreulich und birgt viel Potential. Gleichzeitig stellt sie die Maintainer von vorhandenen Applikationen aber auch vor das Problem der Migration auf die neue Version.

Um Unsicherheiten rund ums Thema .NET Migration zu beseitigen und relevante Sprachneuerungen kennen zu lernen, haben wir zwei Experten eingeladen:

Rainer Stropek, CEO und Co-Founder von Software Architects, zeigt uns mit seiner mitreissenden und begeisternden Art, warum sich die Mühe lohnt und worauf man achten sollte.

Christian Ewald, Software Architekt bei der M&F Engineering, berichtet von seinen eigenen Erfahrungen und Stolpersteine bei der Migration von .NET Framework 4.8 auf .NET 5.

Für alle, die das Webinar verpasst haben, hier geht's zur Aufzeichnung des gesamten Webinars:

Die wichtigsten Punkte haben wir euch in diesem Blog-Beitrag zusammengefasst.

.NET Migration - Warum - Sprachfeatures

Mit jedem Update werden neue Features der Sprache hinzugefügt und viele existierende Möglichkeiten vereinfacht. Das erhöht die Produktivität und den Spass beim Software-Entwickeln enorm! Nachfolgend sind einige Highlights von .NET 6 und .NET 7, die Rainer ganz besonders schön findet:

.NET 6

• Nullable Enable, was Nullable Reference Types ermöglicht, ist ein absolutes Muss
• Implicit Usings führen zu weniger Zeilen Code

.NET 7

• Global Usings ermöglichen das Verhalten von Implicit Usings für non-system Namespaces
• Raw String Literals “““ “““ ermöglichen Strings mit Zeilenumbruch mit konsistenter Formatierung
• Simplified Null Checking: Myfunct(Iconfiguration configuration!!) die beiden Ausrufezeichen erzeugen automatisch einen Null Check des Arguments mit aussagekräftiger Error Message
• Generic Math ermöglicht z.B. eine effizientere Parsing Implementierung
• Record Structs schenkt einem die GetHashCode() Implementierung, was sehr hilfreich für z.B. Hashsets ist
• Var Lambda Functions: Lambda Functions brauchen nicht mehr den expliziten Delegate Func<T>
• List Pattern ermöglicht graphische Pattern Definitionen basierend auf eine Liste
• Static Abstract Templates bringt abstrakte statische Members zu Interfaces

All diese neuen Features werden benutzt, um den "M&F Engineering Tree" zu erzeugen:

.NET Migration - Warum & Wann - Strategische Sicht

Während Sprachfeatures zwar angenehm und relevant sind, sind sie nicht zwingendermassen ein schlagkräftiges Argument für die Migration, sofern diese aufwändig ist.

In den Anfängen von .NET gab es:

• Kein Google, Hyper-V, Facebook oder Kubernetes
• Keine Container
• Keine CI/CD
• Andere Standards (z.B. SOAP)

Das .NET Framework war “Windows Only” und “Closed Source”. Es gab eine offene Ecma Standardisierung, aber die Implementierung war closed.

Mono wurde Open-Source und Cross-Platform entwickelt, um die Standardisierung zu implementieren.

Nachdem Microsoft erkannt hat, wie wichtig Cross-Platform ist, wurde .NET Core entwickelt. Dabei sollte etwas Neues, Kompaktes, Kleines und basierend auf modernsten Technologien entwickelt werden. Durch den Marktdruck von bestehenden Applikationen wurden nach und nach die existierenden Features vom .NET Framework eingeführt.

Der .NET Standard hat die Unterschiede der verschiedenen .NET Implementierungen zu überbrücken versucht. Heute sind wir zurück zu “One .NET”, das alle verschiedenen historischen .NET´s obsolet macht.

Vor diesem Hintergrund ist es essentiell, eine Strategie in Ihrem Unternehmen zu entwickeln, auf .NET 6 zu migrieren und nicht hinter den neuen Versionen zurückzufallen.

.NET Migration - Wie - Ein Erfahrungsbericht

Christian Ewald präsentiert die Migration des Projektes für den Kunden Ionplus von .NET Framework 4.8 auf .NET 5. Bei dem Projekt handelt es sich um eine Maschinensteuerung eines Teilchenbeschleunigers mit Angular und ASP.NET.

Die Gründe für die Migration sind die Folgenden:

• 3rd Party Packages supporten nicht mehr alle .NET Framework 4.8
• .NET Framework Zukunft supported - aber wie lange?
• Neue Sprachfeatures gewollt!
• Technische Schulden abbauen - das .NET Framework zählt zunehmend als technische Schuld

In diesem Projekt war es notwendig, die Migration in kleinen Schritten vorzuführen. Ein “Big Bang” war nicht möglich, da ein Sprint ohne funktionale Ergebnisse nicht mit dem Kunden zu vereinbaren wäre. Stattdessen wurde die Migration stückweise über mehrere Sprints verteilt.

Einige Bereiche die Probleme bereitet haben:

• Es ist Hardware im Einsatz, die spezielle Treiber von ihren Herstellern in .NET benötigen. Diese Treiber gibt es nur auf .NET Framework 4.5 ohne Aussicht auf Updates. Nach einigem Testen und einem Prototypen war klar: Die .NET Framework 4.5 DLL funktioniert problemlos in .NET 5!
• Angedacht war die Migration von ASP.NET Web API 2 über ASP.NET Core 2.2 zu .NET 5. Das war nicht möglich, da andere Komponenten bereits auf .NET 5 waren.

Daher doch Big Bang, nämlich wie folgt:

1. Projekte umstellen → kompiliert nicht mehr!
2. Fake-Implementationen von fehlenden Klassen → kompiliert wieder!
3. Erster Controller migrieren → Test mit Postman
4. Restliche Controller migrieren
5. SignalR Hubs migrieren
6. Startup/Shutdown bereinigen

Die Take-aways aus dem Erfahrungsbericht

• Benutze SDK-style projects
• Benutze .NET Standard 2.0
• Entity Framework 3.1 (läuft in .NET Framework 4.8!)
• Es gibt viele Tutorials - probiert es einfach mal aus!
• Technical Debt - immer daran arbeiten
• Merkbar bessere Performance in der Applikation

Das M&F Team berät und unterstützt Sie gerne bei Ihrer .NET Migration. Schicken Sie einfach eine Anfrage an .