Für .NET-Entwickler gab es auf der Microsoft BUILD 2019 wieder einmal einen ordentlichen Paukenschlag: .NET 5.0 (kurz .NET 5) wird der gemeinsame Nachfolger der drei bisherigen .NET-Varianten (.NET Core, .NET Framework und Mono) sein. Alle .NET-Anwendungsarten von Desktop (WPF und Windows Forms) über Webserver (ASP.NET) und Webbrowser (Blazor/WebAssembly) bis zu Apps (UWP, Xamarin) und Spielen (Unity) sollen damit zukünftig eine gemeinsame .NET-Basis haben.

.NET 5 soll im November 2020 (Abb. 2) erscheinen und im Wesentlichen (aber nicht komplett) plattformneutral sein. Einige Anwendungsarten, die auf .NET 5 basieren, werden nur auf bestimmten Plattformen laufen, z. B. UWP-Apps nur auf Windows 10, WPF- und Windows-Forms-Desktopanwendungen nur auf Windows ab Version 7. .NET 5 darf nicht verwechselt werden mit .NET Core 5 – dem Namen, den Microsoft für .NET Core 1.0 geplant hatte, bevor man sich entschloss, die Versionszählung wieder von vorne zu beginnen.

Nicht alle Features kommen in .NET 5

Technisch gesehen ist .NET 5 die Weiterführung von .NET Core (mit den zugehörigen Werkzeugen und Deployment-Optionen), in das große Teile (aber nicht alles) von .NET Framework und Mono einfließen (Abb. 1). Nach derzeitigem Stand werden in .NET 5 zum Beispiel Windows Workflow Foundation (WF) und Windows-Communication-Foundation-(WCF-)Server sowie Windows Forms aus Mono fehlen. Im Rahmen von .NET 5 wird aus Mono die statische Ahead-of-Time-(AOT-)Kompilierung als Alternative zur bisherigen Just-in-Time-(JIT-)Kompilierung in .NET einfließen, sodass .NET-Entwickler zukünftig zwischen JIT und AOT wählen können. AOT bietet .NET-Entwicklern kleinere Installationspakete und schnellere Anwendungsstarts, aber wegen der Vorkompilierung in Maschinencode eben keine plattformunabhängigen Installationspakete.

.NET 5 wird auch neue Funktionen beinhalten. Dazu gehört eine Integration mit anderen Frameworks und Programmiersprachen (Java, Objective-C und Swift) für die App-Entwicklung auf iOS und Android.

Der Begriff „Core“ verschwindet wieder

„.NET Core“ hatte Microsoft als Namen am 12.11.2014 für das schon am 13. Mai 2014 verkündete „cloud-optimized .NET Framework“ alias „Project K“ eingeführt. Version 1.0 erschien dann am 26. Juli 2016. Danach gab es die Versionen 1.1, 2.0, 2.1, 2.2. Version 3.0 von .NET Core soll im September 2019 erscheinen; auf der BUILD gab es die Preview-5-Version; die Veröffentlichung des Release Candidate ist für Juli dieses Jahres geplant, dann soll es noch ein .NET Core 3.1 im November 2019 geben.

Damit soll dann die .NET-Core-Ära auch schon wieder enden (Abb. 3). Es wird keine weiteren Versionen mehr mit „Core“ im Namen geben. Als Nächstes kommt .NET 5 (Abb. 3), denn Microsoft findet den Begriff inzwischen nicht mehr geeignet in der Kommunikation, gerade für neu in die .NET-Welt eintretende Softwareentwickler.

Mit .NET Core Version 2.0 hatte Microsoft begonnen, massiv Klassen aus dem .NET Framework nach .NET Core zu übernehmen. Man kehrte damit von dem .NET-Core-1.x-Gedanken ab, das neue .NET Core klein und aufgeräumt zu halten. Stattdessen stand nun auf der Agenda, möglichst kompatibel zum .NET Framework zu werden, damit bestehende klassische .NET-Framework-Anwendungen auf .NET Core umziehen können. In Version 2.1 führte Microsoft diese Trendwende mit dem Windows Compatibility Pack (WCP) fort: Erstmals gab es in .NET Core nur Klassen, die ausschließlich auf Windows laufen (z. B. für die Registry-Programmierung). Dies wird verstärkt auch in .NET Core 3.0 gelten: Dort gibt es zwar dann die GUI-Frameworks WPF und Windows Forms, aber sie sind weiterhin nicht plattformunabhängig, sondern an Windows gebunden. Der Sinn von WPF und Windows Forms liegt darin, dass Softwareentwickler bestehende .NET-Framework-basierte WPF- und Windows-Forms-Anwendungen auf .NET Core umziehen können. Auch in .NET 5 wird sich an dieser Plattformeinschränkung erst einmal nichts ändern.

.NET Core 3.0 liefert darüber hinaus .NET Standard 2.1, Unterstützung für gRPC und das neue ASP.NET-SignalR-basierte Webanwendungsmodell Server-side Blazor – nicht zu verwechseln mit dem WebAssembly-basierten Client-side Blazor, das zwar nun eine offizielle Vorschau ist, für das es aber weiterhin keinen Veröffentlichungstermin gibt.

.NET Framework 4.8 auf dem Abstellgleis

Softwareherstellern und Softwareentwicklern, die heute bestehende WPF- und Windows-Forms-Anwendungen besitzen oder neu planen, machte Microsoft auf der Build-Konferenz klar, was sie schon am 4. 10. 2018 in einem Blogeintrag angedeutet hatten: Die am 18. April 2019 erschienene Version 4.8 ist die letzte Version des .NET Frameworks, die signifikante neue Funktionen bieten wird. Alles, was danach noch an Updates kommen wird, wird lediglich Sicherheitslücken und kritische Softwarefehler betreffen. Vielleicht wird das ein oder andere Netzwerkprotokoll noch auf den neuesten Stand gebracht, das wars dann aber.

Deterministische Erscheinungstermine

Microsoft will bei .NET 5 bei der in .NET Core etablierten, agilen und transparenten Entwicklungsweise eines Open-Source-Projekts auf GitHub bleiben. Einen Unterschied soll es aber zu .NET Core geben: Anstelle der bisherigen unregelmäßigen Erscheinungstermine soll es jedes Jahr im November eine neue Hauptversion mit Breaking Changes geben, d. h. nach .NET 5 im November 2020 gibt es dann .NET 6 im November 2021, .NET 7 im darauffolgenden Jahr usw. (Abb. 2).

Zwischendurch sind Unterversionen mit neuen Features, aber ohne Breaking Changes bei Bedarf angedacht. Jede zweite Version soll eine Long-Term-Support-(LTS-)Version mit drei Jahren Unterstützung durch Microsoft sein. .NET Core 3.0 wird genau wie .NET Core 2.0 keine LTS-Version sein; die auf .NET Core 2.1 folgende LTS-Version wird .NET Core 3.1 sein. Dann geht es in der LTS-Linie erst 2021 weiter. Weitere Neuigkeiten von der Microsoft Build:

Windows:

• Ein verbessertes Linux-Subsystem in Windows (WSL) bietet schnellere Dateisystemoperationen sowie die Unterstützung für Linux-basierte Docker-Container.
• Microsoft wird seinem Windows-Betriebssystem endlich ein neues Kommandoeingabefenster (Windows Terminal) mit zeitgemäßer Zeichensatzunterstützung inklusive Emoticons, Registerkarten, Layoutthemen und einem Erweiterungsmodell mit eigenem Marktplatz spendieren. Das Windows Terminal wird für die klassische CMD, die PowerShell und das Shell für Windows for Linux (WSL) zur Verfügung gestellt werden. Die erste Version soll es aber erst im Juni 2019 geben.
• Der neue Chromium-basierte Microsoft-Edge-Webbrowser erhält einen Kompatibilitätsmodus zum Internet Explorer 11 (IE Mode). Unternehmen, die auf Funktionen des Internet Explorers für alte Intranetanwendungen angewiesen sind (z. B. ActiveX), sollen damit auf Edge umsteigen können.

Werkzeuge:

• Von Visual Studio 2019 gibt es eine dritte Vorschauveröffentlichung auf Version 16.1. Die bisher eigenständige IntelliCode-Erweiterung ist nun für die Sprachen C# und XAML enthalten. Auch die GitHub-Erweiterungen gehören nun zum Standard. Ebenso soll die Performance für C++- und .NET-Entwickler in einigen Punkten verbessert sein. In C# gibt es nun IntelliSense auch für Typen, die noch nicht importiert sind.
• Die Visual-Studio-Abonnementoptionen werden erweitert um „Visual Studio Professional with GitHub Enterprise“ und „Visual Studio Enterprise with GitHub Enterprise“ im Rahmen von Enterprise Agreements (EA).
• Entwickler können mit Visual Studio Online (VSO) im Browser coden. Für diesen Onlineeditor verwendet Microsoft wieder den Namen VSO, den man zwischen dem 14. 9. 2011 und dem 13. 12. 2013 als Name für die heutigen Azure DevOps Services verwendete.

.NET:

• Mit .NET Core 3.0 Preview 3 liefert Microsoft eine erste Version des „Single-File Bundlers“ aus, die alle Dateien einer .NET-Core-Anwendungen in eine selbstentpackende Executable verpackt. Eine echte .exe mit AOT-Compiler soll es erst in .NET 5.0 geben.
• Die auf der Build 2018 angekündigten „XAML-Inseln“ werden in Windows 10 mit dem Update im Mai 2019 verfügbar sein. Damit können Steuerelemente der Universal Windows Platform (UWP) in WPF und Windows Forms eingebunden werden (natürlich setzt dies Windows 10 voraus!).
• Mit MSIX Core können Entwickler das MSIX-Installationsformat auch auf Windows-Versionen vor Windows 10 verwenden.
• Ergänzend zur Microsoft Authentication Library (MSAL) for JavaScript sowie Objective-C für iOS und Android gibt es nun diese Hilfsbibliothek für Azure Active Directory auch für .NET.
• ML.NET, die auf der BUILD 2018 angekündigte Machine-Learning-Bibliothek für .NET, erreicht Version 1.0.
• NET-Programmierung ist nun auch dem Cluster-Computing-Framework Apache Spark möglich mit „.NET for Apache Spark“.
• Xamarin Forms 4.0 gibt es als Public Preview, u. a. mit dem neuen CollectionView-Steuerelement, das ListView ersetzen soll, indem es schneller ist.

SQL Server:

• Mit Azure SQL Database Edge liefert Microsoft nun eine sowohl auf x64- als auch auf ARM-Systemen installierbare SQL-Server-basierte Datenbank mit niedrigen Systemanforderungen. Das API der Azure SQL Database Edge soll kompatibel zu SQL Server und SQL Azure sein.

DevOps:

• Für Azure DevOps gibt es ein neues Preismodell. Es gibt keine Preiskategorien mehr: Wer mehr als fünf Benutzer hat, zahlt 6 Dollar pro Benutzer. Für in der Cloud gespeicherte Artefakte zahlt man zukünftig zwischen 2 und 0.25 Dollar pro Gigabyte, wobei die ersten zwei Gigabyte frei sind.
• Durch die Azure-Active-Directory-(AAD-)Unterstützung in GitHub können Entwickler nun Benutzergruppen zwischen dem AAD und GitHub synchronisieren.
• Auf der anderen Seite unterstützten die Webportale für Azure und Azure DevOps nun auch die Benutzeranmeldung mit GitHub-Benutzerkonten.
• Bisher konnten Azure-DevOps-Nutzer die neuen YAML-basierten Pipeline-Definitionen nur für Build-Pipelines nutzen. Nun gibt es dieses Feature auch für Release-Pipelines. Ein einziges YAML-Dokument kann dabei sowohl die Build- als auch die Release-Pipeline enthalten. YAML-Pipeline-Definitionsdokumente können im Quellcodeverwaltungssystem eingecheckt sein. Das gibt den Entwicklern die Möglichkeit, Pipeline-Definitionen auf einfache Weise spezifisch für einzelne Branches zu erstellen.
• Für das Deployment auf Azure Kubernetes Services und Red Hat OpenShift gibt es nun Vorlagen in Azure DevOps, sowohl für Cloud als auch On-Premise.