Microsoft läutet mit .NET Core 3.0 und C# 8.0 neues Zeitalter ein

Inhaltsverzeichnis

Nach einer längeren Preview-Phase mit neun Vorschauversionen und einem Release Candidate zwischen Dezember 2018 und September 2019 können Softwareentwickler nun die endgültige Version von .NET Core 3.0 kostenfrei herunterladen. Enthalten ist der C#-Compiler in Version 3.3, der die Sprachversion C# 8.0 unterstützt. Für die Verwendung beider Produkte empfiehlt Microsoft die Version 16.3 von Visual Studio 2019, auch wenn einzelne Anwender es geschafft haben, Framework und Compiler in ältere Versionen einzubinden.

C# 8.0 wird nicht überall komplett unterstützt

Größte Neuerungen in C# 8.0 sind Standardimplementierungen in Schnittstellen (vgl. entsprechende Neuerung, die es schon in Java 8 als "Default Methoden" gab), Switch Expressions (Methoden, die nur aus einer prägnanten Switch-Verzweigung bestehen), Index- und Range-Operatoren zur Adressierung von Teilmengen sowie asynchrone Streams (asynchrone Iteration mit foreach).

Im Rahmen von Visual Studio 2019 Version 16.3 können auch Softwareentwickler, die noch mit dem klassischen .NET Framework arbeiten, den neuen Compiler nutzen. Allerdings stehen im klassischen .NET Framework – wie angekündigt – einige neue Sprachfeatures nicht zur Verfügung und Microsoft will auch den dafür notwendigen .NET Standard 2.1 nicht mehr für das klassischen .NET Framework anbieten. In Arbeit ist aber die Unterstützung für den kompletten C#-8.0-Sprachumfang in Mono, Xamarin und Unity.

Auf der Ebene der Common Language Runtime (CLR) ist die bisher optionale Tiered Compilation (TC) im Just-In-Time-Compiler nun der neue Standard in .NET Core 3.0. Der JIT-Compiler legt dabei zunächst den Schwerpunkt auf schnelle Übersetzung in Maschinencode statt eines optimalen Ergebnisses. Erst später wird bei häufiger verwendeten Programmteilen die Übersetzung nachträglich optimiert.

Bei den Prozessoren neu ist die Unterstützung für ARM64, allerdings zunächst nur mit Linux-Betriebssystemen. Windows-Nutzer können vorerst keine .NET-Core-Anwendungen schreiben, die auf ARM64-Prozessoren laufen.

.NET Core für den Windows-Desktop

Nachdem die ersten beiden Versionen von .NET Core nur Webserver- und Konsolenanwendungen sowie die Universal Apps für Windows 10 unterstützt haben, können Entwickler nun mit .NET Core 3.0 erstmals auch klassische Desktop-Anwendungen mit der Windows Presentation Foundation (WPF) und mit Windows Forms erstellen. Allerdings verliert eine .NET-Core-Anwendung durch den Einsatz der ".NET Core Windows Desktop Runtime" ihre ansonsten weiterhin gegebene Plattformunabhängigkeit.

Einige Funktionen von WPF und Windows Forms stehen unter .NET Core noch nicht zur Verfügung. Dazu gehören die XAML Browser Application (XBAP) und der grafische Designer für Windows Forms sowie damit einhergehend die Framework-Klassen, mit denen Entwickler den Designer in eigene Anwendungen einbauen können. Microsoft arbeitet jedoch an dem Designer und diskutiert in einem YouTube-Video die Herausforderungen einer Migration des vor fast 20 Jahren entstandenen Designer-Programmcodes auf das aktuelle .NET Core. Für WPF ist der auf .NET Core angepasste Designer bereits in Visual Studio 2019 Version 16.3 enthalten.

Für Windows Forms gibt es in .NET Core 3.0 eine neue Funktion zur Anpassung der Oberfläche an hochauflösende Anzeigegeräte, die es im klassischen .NET Framework nicht gab (siehe Application.SetHighDpiMode()). SetHighDpiMode() wirkt allerdings nur vor dem Öffnen des ersten Fensters.

Entity Framework auf .NET Core

In Hinblick auf die Migration bestehender .NET-Framework-Anwendungen auf .NET Core hat Microsoft auch die klassische Variante seines objektrelationalen Mappers, ADO.NET Entity Framework, auf .NET Core umgestellt. Die neue Version 6.3 bietet keine neuen Features außer der Lauffähigkeit auf .NET Core. Auch hier fehlt noch der grafische Designer.

Entwickler, die dennoch schon jetzt mit Windows Forms und Entity Framework in .NET Core starten wollen, können als Problemumgehung vorerst die zugehörigen Designer in einem klassischen .NET-Projekt verwenden und das Resultat in ein .NET-Core-Projekt verlinken.

Microsoft betont jedoch, dass man neue Projekte nicht mit Entity Framework, sondern nur mit Entity Framework Core starten sollte. In Version 3.0 hat Microsoft die Übersetzung von LINQ zu SQL komplett überarbeitet, sodass nun zum Beispiel auch Union-Operationen, Subqueries und komplexere "Group By"-Anweisungen in SQL übersetzt werden können. Die gefährliche automatische Client Evaluation, die hilfsweise alle Daten einer Tabelle zur Verarbeitung ins RAM holte, wurde abgeschafft.

Neben einigen kleineren Verbesserungen beim Reverse Engineering und dem schon lange in der Entwicklung befindlichen Datenbanktreiber für den Cloud-Datenbankdienst Cosmos DB gibt es ansonsten wenig Neuerungen in Version 3.0, sondern vor allem zahlreiche Breaking Changes, die zum Teil umfangreiche Änderungen an bestehendem Programmcode erfordern. Microsoft will sein Produkt damit auf neue Features vorbereiten, die dann in der Zukunft erscheinen sollen.

Neue Verbreitungswege

Insbesondere in Hinblick auf die wiederentdeckte Desktop-Welt bietet .NET Core neue Deployment-Funktionen. Eine .NET-Core-Anwendung erzeugt nun direkt beim Kompilieren eine .exe-Datei, nicht wie bisher erst beim Publish-Befehl. In einem Single-File Executable bündeln Entwickler alle zu einer Anwendung notwendigen DLLs und weitere Dateien zu einer .exe-Datei zur vereinfachten Weitergabe. Allerdings findet hier nicht wie ursprünglich angekündigt ein Tree Shaking statt: Die EXE ist nur ein gepacktes Archiv aller Dateien, das beim Start nach C:\Users\xy\AppData\Local\Temp\.net\ entpackt wird.

Mit dem optionalen Einsatz des IL Linker aus Mono können .NET-Core-Entwickler immerhin DLLs im Deployment-Paket loswerden, die gar nicht gebraucht werden. Sofern Reflection oder andere dynamische Techniken verwendet werden, müssen Entwickler aber dem Linker bei der Erkennung helfen, was gebraucht wird. Mit dem Feature "ReadyToRun Images" (R2R) bringt das neue Werkzeug CrossGen parallel zum Intermediate Language Code auch den zugehörigen Maschinencode in das Kompilat ein. Die Anwendungsdateien werden dadurch größer, starten aber schneller. Ein vollständiger Ahead-of-Time-Compiler mit Tree Shaking soll dann im .NET-Core-Nachfolger mit Namen .NET 5.0 im November 2020 erscheinen.

Als weitere Deployment-Option können .NET-Core-Entwickler nun auch das neuere MSIX-Installationspaketformat verwenden, indem sie in Visual Studio 2019 ab Version 16.3 ein Windows Application Packaging Project für eine .NET-Core-Desktop- oder Konsolenanwendung erstellen. Per MSIX installierte Anwendungen können beim sich Anwendungsstart selbst von einer Webseite oder einem Netzlaufwerk aktualisieren. Damit ist MSIX ein Ersatz für das entfallene Click-Once-Deployment.

Mit der neuen Funktion "Major-version Roll Forward" können Entwickler oder Betreiber einer Anwendung nun steuern, dass eine ältere .NET-Core-Anwendung mit der neuesten .NET-Core-Laufzeitumgebung starten soll.

Für Entwickler bietet das .NET Core Software Development Kit (SDK) nun auch lokale Werkzeuge an, die nur für ein Verzeichnis auf der Festplatte und die Unterordner gelten. Das hat Microsoft aus dem Node Package Manager (NPM) abgeschaut.

Server Side Blazor

Für Webentwickler gibt es in ASP.NET Core 3.0 eine erste Version des ersehnten "ASP.NET Blazor", mit denen sie Single Page Applications (SPA) in .NET mit Razor Components schreiben können. Die in ASP.NET Core 3.0 enthaltene Variante "Blazor Server App" alias "Server Side Blazor" läuft allerdings nicht auf Basis von WebAssembly im Browser, sondern – wie der Name auch ausdrückt – auf dem Webserver.

Dass Benutzer dennoch das Erlebnis einer SPA bekommen, liegt am Einsatz von ASP.NET Core SignalR, das die Benutzerinteraktionen mit der Webseite per Websocket zum Server sendet und die auf dem Server vorgenommenen Änderungen auf Document Object Model (DOM) zum Browser überträgt. Das dazu notwendige Shadow DOM auf dem Webserver für jeden angeschlossenen Browser schränkt allerdings die Skalierbarkeit ein und ist nicht Offline-fähig. Das Modell eignet sich für Webanwendungen mit kleineren Benutzerzahlen und bietet eine einfache Migrierbarkeit auf das Client-seitige Blazor, das mit WebAssembly im Browser läuft, für das es aber weiterhin keinen verkündeten Erscheinungstermin gibt.

ASP.NET Core nicht mehr auf .NET Framework

Mit ASP.NET Core 3.0 setzt Microsoft nun um, was bereits für die Version 2.0 angedroht war: Das Webframework läuft nicht mehr auf dem klassischen .NET Framework, sondern nur noch auf .NET Core. Gleiches gilt nun überraschend auch für Entity Framework Core. Alle Kunden, die das klassische .NET Framework als Basis für ASP.NET Core oder Entity Framework Core genutzt haben, müssen nun auf .NET Core umsteigen oder sind von Weiterentwicklungen ausgeschlossen.

Immerhin hat Microsoft angekündigt, den Support für ASP.NET Core 2.1 inklusive Entity Framework Core 2.1 auf .NET Framework abweichend von der Support-Richtlinie zu verlängern. Das sich dies auf Version 2.1 und nicht auf die Version 2.2 bezieht, liegt daran, dass erstere die Long-Term-Support-Version ist und Microsoft hier die zusätzlichen Kosten der längerfristigen Unterstützung einer weiteren Version einsparen will.

Google RPC und Systemdienste

Als Ersatz für die in .NET Core auf der Serverseite nicht mehr angebotene Windows Communication Foundation (WCF) bietet Microsoft nun neben den seit der ersten Core-Version vorhandenen REST-basierten WebAPIs auch die Unterstützung für das auf HTTP/2 und Protocol Buffers aufsetzende Google RPC als Client und Server an.

Für die Erstellung von im Hintergrund laufenden Systemdiensten kann .NET Core 3.0 die Projektvorlage "Worker Service" und die Pakete Microsoft.Extensions.Hosting.WindowsServices für Windows und Microsoft.Extensions.Hosting.Systemd für Linux nutzen.

Weitere neue Klassen

.NET Core 3.0 ist die erste .NET-Variante, die .NET Standard Version 2.1 implementiert. Zu den neuen Klassen in .NET Core 3.0 gehören neben den Basisklassen für einige Sprachfeatures (z.B. System.Index, System.Range, System.Span<T>, System.Memory<T>, System.ValueTask<T>) auch einige alte Tanten aus den Gründertagen von .NET wie die dynamische Codegenerierung mit Reflection Emit, die Abstraktion von Datenbankprovidern mit DbProviderFactories und sogar alte Visual Basic APIs, die auch in C# nutzbar sind.

Außerhalb des .NET Standard beherrscht .NET Core 3.0 nun auch die Interoperabilität mit COM- und WinRT-Komponenten (nur auf Windows), das Laden nur der Metadaten aus Assemblies (MetadataLoadContext) und das Entladen geladener Assemblies (AssemblyLoaderContext. Auch ein neue Bibliothek für JSON-Serialisierung und -Deserialisierung ist enthalten (System.Text.Json) und kommt in ASP.NET Core unter anderem bei Web APIs zum Einsatz, nachdem sich Microsoft mit James Newton-King, dem Autor des bisher verwendeten JSON.NET, nicht auf eine Umgestaltung einigen konnte.

Die Klasse System.Net.Http.HttpClient unterstützt nun HTTP/2. Unterstützung für TLS 1.3 gibt es auch in .NET Core 3.0, aber bisher nur auf Linux. Serielle Schnittstellen, die bisher nur unter Windows programmierbar waren, sind jetzt auch unter Linux nutzbar. In der Mathe-Bibliothek System.Math finden Entwickler neue Funktionen wie BitIncrement(Double), BitDecrement(Double), MaxMagnitude(Double, Double), MinMagnitude(Double, Double), ILogB(Double), ScaleB(Double, Int32) und CopySign(Double, Double).

Eine kleine, aber doch sehr hilfreiche Neuerung in .NET Core 3.0 ist, dass die APIs, die Aufschluss über die laufende .NET-Version (System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription und System.Environment.Version) geben, nun unter .NET Core die korrekte Versionsnummer 3.0 melden. In .NET Core 1.x und 2.x bekamen Aufrufer immer eine Versionsnummer zurück, die mit 4 begann und an das klassische .NET Framework angelehnt war. (ane)