Microsoft hat es auf der Build angekündigt: Die Weiterentwicklung von .NET findet in .NET Core statt:

There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more. (link)

(Quelle: Microsoft)

Die nächste Version wird .NET 5 heißen und das derzeitige .NET Core (2.x bzw. 3.0) mit Mono zusammenführen:

“Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono.” (link)

In einem weiteren Blog-Beitrag macht Microsoft auch deutlich, was das für das klassische .NET Framework bedeutet:

“.NET Framework 4.8 will be the last major version of .NET Framework. If you have existing .NET Framework applications that you are maintaining, there is no need to move these applications to .NET Core. We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes.” (link)

Reaktionen

Die Ankündigung kam für manche überraschend, für andere war sie absehbar und eine logische Konsequenz. Für den einen ist das keine große Sache, weil er seine Web-Anwendung ohnehin bereits mit .NET Core schreibt, der andere hat Bedenken, weil “sein” .NET Framework angeblich abgekündigt wurde. Man findet sogar Trolle, die behaupten, jetzt müsste jede Anwendung neu geschrieben werden.

Fakten

Das wichtigste zuerst: Wie es im Zitat oben heißt: Das klassische .NET Framework ist nicht abgekündigt. Bestehende Anwendungen müssen nicht neu geschrieben werden.
Ich würde sogar noch einen Schritt weitergehen: Es kann durchaus sinnvoll sein, auch jetzt noch neue Anwendungen mit .NET Framework zu schreiben. Es gibt einige Teile im .NET Framework, die es unter .NET Core bzw. .NET 5 (Stand heute) nicht geben wird; prominentestes Beispiel ist sicher WCF.
Fakt ist aber auch, dass in den nächsten Jahren der Migrationsdruck zunehmend wachsen wird, denn neue Features werden nur .NET Core zugute kommen. Je früher man auf diesen Zug aufspringt (wenn machbar), desto besser.

Konsequenzen

Wer im Web- oder Cloud-Umfeld unterwegs ist, dürfte bereits auf .NET Core sein. Er kann sich freuen auf das richtige Pferd gesetzt zu haben, und sicher sein, dass “seine” Plattform in Zukunft noch besser unterstützt wird.

Auch für Mobile- bzw. Xamarin-Entwickler ist das eine gute Nachricht, denn die parallele Entwicklung zweier Plattformen – hier Mono – kann auf Dauer nur zu Problemen führen, ohne dabei einen Vorteil zu bringen. Die Argumente der Vergangenheit – Open Source und Plattformunabhängigkeit – sind mit .NET Core hinfällig.

Bleibt noch die Entwicklung mit klassischem .NET Framework. Hier muss man drei Szenarien unterscheiden:

• Keine einfache Migration möglich
• Eine einfache Migration ist möglich
• Die Migration hängt von Fremdbibliotheken ab

Keine einfache Migration

Schlecht sieht es aus für…

• ältere Web-Anwendungen auf Basis von ASP.NET WebForms, HTTP-Modulen, etc.
• Services auf Basis von WCF, .asmx oder Remoting
• Anwendungen die AppDomains oder Code Access Security verwenden
• und vermutlich noch ein paar weitere …

Diese Technologien sind bereits veraltet oder müssen mit der Ankündigung Microsofts als veraltet angesehen werden. Im Falle von WCF kann man hier durchaus anderer Ansicht sein, was auch durchaus kontrovers diskutiert wird. Die Aussage von Microsoft ist aber eindeutig:

“If you are a remoting or WCF Server developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC”. (link)

Hier muss entschieden werden, ob es sich lohnt, die Anwendung auf alternative Technologien zu migrieren. Die häufigere Vorgehensweise dürfte jedoch sein, die Anwendung einfach weiterzupflegen – wohlwissend, dass damit jede relevante Investition in neue Funktionalitäten fehl am Platz ist.

Einfache Migration

Glück haben Entwickler von WPF-, WinForms- oder UWP-Anwendungen, denn diese werden mit .NET Core 3.0 unterstützt. Ebenso Anwendungen, die ADO.NET gegen den SQL Server nutzen.

Daneben gibt es das Windows Compatibility Pack for .NET Core, mit dem auch aus .NET Core-Anwendungen heraus unter Windows der Zugriff zum Beispiel auf das EventLog möglich ist. Abgerundet wird das mit der entsprechenden Dokumentation mit Anleitungen zum Migrationsprozess.

Allerdings darf man keine relevante Fremdbibliothek im Einsatz haben, sonst landet man in der nächsten Gruppe.

Abhängigkeit von Fremdbibliotheken

Die meisten nicht-trivialen Anwendungen – gerade auch, wenn sie schon älter sind – nutzen neben dem eigentlichen .NET Framework noch weitere 3rd Party Bibliotheken. Typische Vertreter sind:

• Microsoft Enterprise Library (link) der patterns&practices group bei Microsoft
• MVVM Frameworks wie Caliburn Micro
• Dependency Injection Frameworks wie Castle Windsor
• OR-Mapper wie NHibernate
• Logging-Frameworks wie log4net

Die meisten der genannten Beispiele beeinflussen die Anwendungsarchitektur massiv und sind nicht leicht austauschbar. Daher müssen sie in einer Variante für .NET Standard verfügbar sein, damit eine Migration der eigenen Anwendung möglich ist. Das ist bei vielen der Bibliotheken der Fall; Caliburn Micro scheint allerdings im Alpha-Stadium festzuhängen. Wer auf die Enterprise Library gesetzt hat, hat allerdings ein Problem.

Fazit

Auf lange Sicht ist die Ankündigung, die Plattform auf Basis von .NET Core zu vereinheitlichen zu begrüßen – ein plattformübergreifendes, von Altlasten befreites und an vielen Stellen verbessertes .NET Framework – wer könnte da nein sagen?
Und die Versuche der Vergangenheit – von unterschiedlichen Laufzeitumgebungen bis zu Portable Libraries – haben ihre Nischen nie verlassen können.

Kurz- und mittelfristig sorgt die Ankündigung aber für einen deutlichen Aufschlag auf den Wartungsbedarf bestehender Anwendungen.

Immerhin eins muss man Microsoft aber zugestehen: Es gibt eine klare Aussage. Keinen Eiertanz wie seinerzeit zu Silverlight.