Build 2019: Microsoft konkretisiert die Pläne für .NET 5.0

Nachdem .NET 5.0 als Nachfolger von .NET Core, .NET Framework und Mono/Xamarin feststeht, benennt Microsoft nun die dabei wegfallenden Techniken.

In Pocket speichern vorlesen Druckansicht 24 Kommentare lesen
Build 2019: Microsoft führt Mono und .NET Core zusammen zu .NET 5.0
Lesezeit: 4 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Die Liste der Techniken, die Microsoft nicht aus dem .NET Framework nach .NET Core beziehungsweise dem gestern angekündigten Nachfolger .NET 5 übernehmen will, überrascht nicht. Aber die Aussage des Herstellers dazu ist nun konkreter als in der Vergangenheit. In ihrem Vortrag ".NET Platform Overview and Roadmap" gingen die Microsoft-Manager Scott Hanselman, Partner Program Manager, und Scott Hunter, Director Program Management, gegen Ende auch auf .NET 5 ein und stellten klar, welche Techniken das Unternehmen nicht mehr aus dem alten .NET Framework in die neue Welt von .NET Core/.NET 5 übernehmen werde.

Zu den "sterbenden" Techniken gehören das auf serverseitigen Steuerelementen basierende Webserverentwicklungsframework "ASP.NET Webforms", die "ASP.NET Webservices" und ".NET Remoting" (alle eingeführt in .NET Framework 1.0 im Januar 2002), die Entwicklung von SOAP-Webservices und REST-Diensten mit der Windows Communication Foundation (WCF) und die Windows Workflow Foundation (WF). WCF und WF wurden in .NET Framework 3.0 im November 2006 veröffentlicht.

In dem oben genannten Vortrag sagt Scott Hunter: "Leute werden fragen: Warum werden diese Techniken nicht portiert?" Seine unmissverständliche Antwort darauf lautet: "Es dauert Jahre. Und sie werden nicht kompatibel sein." In einem Blogbeitrag stellt Hunter außerdem klar, dass es nach .NET Core 3.0, in das die Desktop-GUI-Frameworks Windows Forms und Windows Presentation Foundation (WPF) aus dem klassischen .NET Framework übernommen werden, überhaupt keine Portierungen in diese Richtung mehr geben wird: "After .NET Core 3.0 we will not port any more features from .NET Framework."

Auffallend ist, dass Hunter im Blog immer von ".NET Core" spricht – so lautet auch der Titel: ".NET Core is the Future of .NET". In dem Vortrag wird die Zukunft aber als ".NET 5" bezeichnet. Das kann verwirren, ist aber in dem Kontext zu verstehen, dass das für November 2020 geplante .NET 5 technisch gesehen der Nachfolger von .NET Core 3.1 (geplant für November 2019) sein wird. Microsoft verzichtet lediglich auf das "Core" im Namen und die Versionsnummer "4.0".

Inkonsistent ist bei Microsoft aber auch noch die Bezeichnung: Einerseits wird der Nachfolger mit .NET 5.0 (s. Roadmap in Abb. 1) benannt, an anderer Stelle – wie im Build-Vortrag vom 6. Mai – nur mit .NET 5 (s. Abb. 2).

Roadmap für .NET Core 3.0 und seine Nachfolger (Abb. 1)

(Bild: Microsoft)

Transition von .NET Framework, .NET Core und Mono/Xamarin zu .NET 5 (Abb. 2)

(Bild: Microsoft)

Scott Hunter rät Microsoft-Kunden dazu, alle neuen Anwendungen ab jetzt nur noch mit .NET Core zu schreiben – meint damit aber sicherlich auch die Nachfolger ohne Core im Namen (.NET 5.0, .NET 6.0, .NET 7.0 usw.). Für bestehende Anwendungen werde das klassische .NET Framework allerdings in Windows erhalten bleiben, weil Windows selbst Funktionen aus .NET verwendet. Jedoch wird es nach dem im April erschienenen .NET Framework 4.8 dafür keine neuen Features, sondern nur noch Fehlerbehebungen und Updates im Bereich Sicherheit und Zuverlässigkeit geben. Nur an den .NET-Werkzeugen in Visual Studio werde Microsoft weiterarbeiten.

Bestehende Anwendungen auf Basis von .NET Framework, die zu den "sterbenden" Techniken zählen, können also erhalten bleiben. "Sagt euren Chefs nicht, dass ihr alles portieren müsst", betonte Hunter im Vortrag. Nur wenn Softwarehersteller neue Funktionen aus .NET Core/.NET 5 nutzen wollen, sei eine Migration erforderlich.

Bei einer solchen Migration empfiehlt Microsoft, bestehende Webforms-Anwendungen auf ASP.NET Blazor umzuziehen. Anstelle von .NET Remoting oder WCF sollen die Kunden Google RPC (gRPC) nehmen, das Microsoft genau wie Server-Side Blazor in .NET Core 3.0 unterstützt. Für Windows Workflow gibt es unter dem Namen CoreWF eine Portierung nach .NET Core aus der Nutzergemeinde. (map)