Umstieg von .NET Framework auf .NET 10: wie viel Arbeit es ist und wie Sie anfangen

Die Anwendung auf .NET Framework 4.x läuft seit zehn Jahren. Das Geschäft läuft darauf, Kunden nutzen sie, und niemand will sie anfassen. Dann kommen ein paar Dinge auf einmal zusammen: Eine neue Bibliothek, die Sie brauchen, unterstützt das Framework nicht mehr, ein guter Kandidat sagt ab, als er hört, woran er arbeiten würde, und das Hosting lässt sich weder in Container noch auf Linux umziehen.

Dann ist der Umstieg auf modernes .NET keine Frage des Ob mehr, sondern des Wie und in welcher Reihenfolge.

Ist es dringend?

Ehrlich gesagt: Es brennt nicht. .NET Framework 4.8.1 ist die letzte Version, und Microsoft unterstützt es, solange es auf einer unterstützten Windows-Version läuft, ohne angekündigtes Enddatum. Sicherheitsupdates kommen weiterhin.

Aber es ist eine Sackgasse. Neue Funktionen, Performance und Bibliotheken kommen nur noch in modernes .NET, und .NET 10 ist eine Version mit Langzeitsupport bis November 2028. Jedes Jahr auf dem Framework bedeutet mehr Code, der später umziehen muss, und weniger Leute, die ihn warten wollen. Der günstigste Zeitpunkt für den Umstieg ist, bevor Sie etwas dazu zwingt.

Was sich leicht portieren lässt und was nicht

Teil der Anwendung	Wie schwer	Wie
Bibliotheken mit Geschäftslogik	Leicht	Der meiste Code läuft unverändert, mit dem neuen Projektformat
Entity Framework 6	Leicht	Läuft auch auf modernem .NET, der Wechsel zu EF Core kann später kommen
Windows Forms und WPF	Mittel	Lassen sich portieren, bleiben aber reine Windows-Anwendungen
ASP.NET MVC und Web API	Mittel	Controller sind ähnlich, Start, Filter und Anmeldung ändern sich
WCF-Clients	Mittel	Client-Pakete gibt es für modernes .NET
WCF-Dienste	Schwerer	CoreWCF oder Umstieg auf REST oder gRPC
Web Forms	Am schwersten	Gibt es in modernem .NET nicht, also werden die Bildschirme neu gebaut, etwa in Blazor
AppDomains, Remoting, Code Access Security	Am schwersten	Gibt es nicht, dieser Teil muss anders konzipiert werden

Die meisten Geschäftsanwendungen haben etwas aus jeder Zeile, deshalb ist eine echte Schätzung immer die Summe der Teile. Die Tabelle zeigt auch, wo der Großteil der Arbeit liegt: in der Webschicht und in den alten Technologien, nicht in der Geschäftslogik.

Wie man anfängt

1. BestandsaufnahmeProjekte, Pakete, Abhängigkeiten
2. BibliothekenVon unten nach oben, für beide Welten
3. WebschichtEine neue App vor der alten
4. AbschaltenDer alte Teil wird stillgelegt

1. Bestandsaufnahme. Alle Projekte, NuGet-Pakete und Abhängigkeiten, mit den Teilen aus den unteren Zeilen der Tabelle markiert. Das Modernisierungswerkzeug von Microsoft in GitHub Copilot hilft zu finden, was nicht kompiliert, aber die Entscheidungen über die Reihenfolge trifft weiterhin ein Mensch.

2. Bibliotheken, von unten nach oben. Zuerst die Projekte, von denen nichts abhängt, dann die darüber. Jede Bibliothek wechselt zuerst auf das neue Projektformat und wird dann für beide Welten gleichzeitig gebaut. So läuft die alte Anwendung weiter, und neuer Code nutzt bereits dieselben Bibliotheken:

   <PropertyGroup>
     <TargetFrameworks>net48;net10.0</TargetFrameworks>   <!-- dieselbe Bibliothek für alte und neue App -->
   </PropertyGroup>

   Was in modernem .NET fehlt und nur unter Windows genutzt wird, deckt oft das Windows Compatibility Pack von Microsoft ab, mit rund zwanzigtausend APIs.

3. Die Webschicht, Stück für Stück. Eine neue ASP.NET-Core-Anwendung steht vor der alten und übernimmt eine Route nach der anderen, alles andere leitet sie an die alte App weiter. Nutzer merken den Umzug nicht, Anmeldung und Session sind gemeinsam, und es gibt keinen großen Tag, an dem sich alles auf einmal ändert. Für Web Forms ist es derselbe Weg, den wir auf der Seite über den Umstieg von Web Forms auf Blazor beschreiben.

4. Abschalten. Wenn die letzte Route umgezogen ist, wird die alte Anwendung abgeschaltet, und die Bibliotheken können das alte Ziel net48 streichen.

Wie viel Arbeit es ist

Das hängt fast ausschließlich von der Webschicht und den unteren Zeilen der Tabelle ab. Bibliotheken mit Geschäftslogik sind oft eine Sache von Tagen oder Wochen. Eine kleinere ASP.NET-MVC-Anwendung ist meist eine Sache von Wochen, eine große Web-Forms-Anwendung oder ein System auf WCF-Diensten eine Sache von Monaten, aber auch dann Stück für Stück, während die Anwendung die ganze Zeit läuft.

Der teuerste Ansatz ist, alles von Grund auf neu zu schreiben und das Alte parallel zu warten. Warum das Neuschreiben von Grund auf selten gelingt, steht im Artikel über technische Schulden.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien, und die Modernisierung alter .NET-Systeme gehört zu den Dingen, die wir am häufigsten machen. Wir beginnen mit einer Einschätzung: Bestandsaufnahme der Projekte und Abhängigkeiten, was sich leicht portieren lässt, was überarbeitet werden muss und in welcher Reihenfolge, mit einem groben Aufwand für jeden Teil. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Supportrichtlinie für .NET Framework, Microsoft
• Übersicht über die Portierung von .NET Framework zu .NET, Microsoft Learn
• In .NET nicht verfügbare .NET Framework-Technologien, Microsoft Learn
• Verwenden des Windows Compatibility Pack, Microsoft Learn
• GitHub Copilot App-Modernisierung für .NET, Microsoft Learn
• CoreWCF, .NET Foundation