.NET 5.0 ist erschienen
Microsoft hat nun die fertige Version von .NET 5.0 veröffentlicht. heise Developer gibt einen Überblick über die wichtigsten Neuerungen.
(Bild: Denis Linine/Shutterstock.com)
- Dr. Holger Schwichtenberg
Das nun im Rahmen der virtuellen .NET Conf 2020 erschienene .NET 5.0 ist technisch der Nachfolger von .NET Core 3.1. Die Versionsnummer 4.0 wird übersprungen und der Begriff "Core" im Namen entfällt wieder. Damit möchte das Microsoft-Marketing ausdrücken, dass sich .NET 5.0 als gemeinsamer Nachfolger der drei bisher getrennten .NET-Varianten .NET Framework, .NET Core und Mono versteht.
Tatsächlich ist die Vision "One .NET" aber noch nicht realisiert in .NET 5.0. Während das .NET Framework seit dem 19. April 2019 auf dem Abstellgleis steht, geht die Entwicklung von Mono und der darauf aufbauenden Xamarin-Plattform weiter, denn Microsoft ist mit der Integration noch lange nicht fertig. Immerhin bei Blazor WebAssembly hat der Hersteller die Mono-Klassenbibliothek inzwischen gegen die .NET-5.0-Klassenbibliothek ausgetauscht (s. Abb. 1). Die in Blazor WebAssembly eingesetzte Laufzeitumgebung ist aber dort weiterhin Mono-basiert und verwendet einen Interpreter statt eines Just-in-Time-Compilers. Die angekündigte Integration der Erstellung mobiler Anwendungen für iOS, Android und Windows mit Xamarin (einschließlich Xamarin.Forms) soll nun erst in .NET 6.0 erfolgen.
(Bild: Holger Schwichtenberg)
Anwendungsarten
Mit .NET 5.0 können Entwickler folgende Anwendungsarten entwickeln:
- ASP.NET Core 5.0-basierte Webanwendungen mit Server-Side-Rendering oder Single-Page-Apps mit Client-Side-Rendering (mit Blazor)
- Webservices (REST-basierte WebAPIs und Google RPC)
- Konsolenanwendungen
- Hintergrunddienste
- Desktop-Anwendungen mit Windows Forms und Windows Presentation Foundation (WPF) für Windows ab Version 7
- Windows Universal Apps und Desktop-Anwendungen für Windows 10 mit der Windows UI Library 3 (Erscheinungstermin geplant für Frühjahr 2021)
Es gibt also weiterhin keine Cross-Platform-GUI-Bibliothek in .NET 5.0. Softwareentwickler, die eine Desktop-Anwendung entwickeln wollen, müssen den Target Framework Moniker "net5.0-windows" anstelle von "net5.0" einsetzen und sind damit auf das Windows-Betriebssystem beschränkt.
Der objektrelationale Mapper Entity Framework Core und das Web-Framework ASP.NET Core haben in .NET 5.0 das "Core" im Namen behalten, um sich von ihren klassischen Vorgängern abzugrenzen. Allerdings hat Microsoft eine neue technische Beschränkung eingeführt. Entity Framework Core 5.0 (die Nummer 4.0 wurde auch hier übersprungen) läuft nur noch auf Plattformen, die .NET Standard 2.1 unterstützt. Das sind .NET 5.0, .NET Core 3.x und Mono ab Version 6.4. Das klassische .NET Framework 4.8 und seine Vorgänger gehören aber leider nicht dazu. Dies bedeutet, dass Entwickler, die bisher Entity Framework Core 1.0 bis 3.1 auf dem klassischen .NET Framework verwendet haben, nun in einer Sackgasse stehen. Support für Entity Framework Core 3.1 gibt es wie für .NET Core 3.1 nur noch bis zum 3. Dezember 2022.
Diese Ausgrenzung des klassischen .NET Framework hatte Microsoft bei ASP.NET Core schon im September 2019 mit Version 3.0 vollzogen. Lediglich ASP.NET Core 1.0 bis 2.2 liefen auch auf dem klassischen .NET Framework.
betterCode() präsentiert: .NET 5.0 – Das Online-Event am 3. Dezember 2020
Das können Sie lernen:
- Von .NET Framework über .NET Core zu .NET 5.0: Was bedeutet das für die Migration, und wie groß sind die Aufwände?
- Was ist neu in .NET 5.0?
- Neue Features: ASP.NET Core 5.0 und Blazor 5.0 kennen lernen
- Die wichtigsten Sprachneuerungen in C# 9
- Mobile Entwicklung mit .NET 5
- OR-Mapping mit Entity Framework Core 5.0
- WinUI 3 als Alternative zu WPF und UWP
- Ausblick auf .NET 6.0
Support nur bis Februar 2022
.NET 5.0 ist im Gegensatz zu .NET Core 3.1 keine LTS-Version (Long-Term Support), sondern wird von Microsoft voraussichtlich nur bis Februar 2022 unterstützt. Das sind drei Monate nach dem Erscheinen von .NET 6.0, das in genau einem Jahr kommen soll. Entwickler, die jetzt auf .NET 5.0 setzen, müssen also schon Ende nächsten Jahres wieder auf .NET 6.0 migrieren. Erst .NET 6.0 wird dann wieder drei Jahre Support bieten.
Viele Verbesserungen im ORM-Mapper
Die meisten und gravierendsten Verbesserungen in .NET 5.0 haben Entity Framework Core und ASP.NET Core Blazor erhalten.
Entity Framework Core 5.0 beherrscht nun wie sein klassischer Vorgänger die Abstraktion von N:M-Beziehungen und das Table-per-Type-Mapping (TPT), mit dem jede Klasse in Vererbungshierarchie auf eine eigene Datenbanktabelle abbildbar ist. Bisher setzte Microsoft auf explizite Klassen für Zwischentabellen und die Zusammenfassung einer ganzen einer Vererbungshierarchie in einer Tabelle (Table-per-Hierarchy – TPH), was die Migration vom klassischen Entity Framework zu Entity Framework Core erschwerte und die Nutzung bestehender Datenbankschemata nicht unmöglich, aber zuweilen unschön machte.
Darüber hinaus bietet Entity Framework Core über 80 weitere Verbesserungen in den Bereichen Mapping, Abfragen mit LINQ und SQL, Persistierung von Änderungen und den Kommandozeilenwerkzeug. Die wichtigsten Verbesserungen sind in einem Blogeintrag aufgelistet.
Hilfreiche Erweiterungen für Blazor
Blazor WebAssembly 5.0 bietet nun auch das bisher sehr vermisste Lazy Loading von Komponenten, wodurch man die Startzeit deutlich verringern kann. Beim Rendering in Blazor WebAssembly-basierten Anwendungen können Entwickler nun wählen, ob eine statische HTML-Seite vorab erzeugt werden soll. Microsoft hat die Ausführungsgeschwindigkeit von Blazor WebAssembly insgesamt deutlich verbessert (vgl. Leistungsmessungen im Blogeintrag).
Alle weiteren Überarbeitungen betreffen auch die Schwestertechnik Blazor Server. So können Entwickler JavaScript-Code, der sich bisher nur global einbinden ließ, nun bei Bedarf nachladen. Razor Components können jeweils eine eigene CSS-Datei besitzen, die nur für die jeweilige Komponente gilt.
Als neue Steuerelemente liefert Microsoft InputRadio und InputRadioGroup sowie InputFile zum Datei-Upload. Den Fokus auf ein Steuerelement sowie die Elemente in <head> des HTML-Dokuments können Entwickler nun auch ohne JavaScript-Einsatz setzen. Ebenso unterstützt Blazor 5.0 nun das Browser-Ereignis ontoggle für das HTML-Tag <details>. Blazor bietet nun eine Komponente <Virtualize>, die aus einer Objektmenge allein die sichtbaren Elemente rendert.
Die seit langem im Preview-Status verweilenden Zusatzdienste ProtectedLocalStorage und ProtectedSessionStorage gehören nun offiziell zum Blazor-Produkt. Weitere Funktionen, die für Blazor 5.0 ursprünglich geplant waren (z. B. AOT-Kompilierung, SVG-Unterstützung, Pflichtparameter in Komponenten), wurden allerdings leider gestrichen.
Ungünstig für einige Blazor-Fans ist die Entscheidung von Microsoft, in Blazor Server sowohl den Internet Explorer (bisher per Polyfill möglich) als auch den klassischen Edge-Browser (vor Version 79) nicht mehr zu unterstützen. Bei Blazor WebAssembly war der Internet Explorer sowieso außen vor, weil es keine WebAssembly-Umgebung anbietet. Hier entfällt aber nun auch der alte Edge.
Weitere Verbesserungen für ASP.NET Core
Auch für klassische ASP.NET-basierte, serverseitige Techniken wie MVC und Razor Pages gibt es Verbesserungen, zum Beispiel Unterstützung für die C# 9.0 Records bei Model Binding und Validation. In Razor Pages können Entwickler jetzt Properties mit der Annotation [CompareAttribute] vergleichen. In Web APIs sind bei der Annotation [FromBody] nun auch optionale Parameter möglich.
In allen Projektenvorlagen für ASP.NET Core WebAPIs bietet Microsoft nun im Standard das Community-Paket Swashbuckle.AspNetCore für die Open API Specification (OAS) der Dienste an (s. Abb. 2). Beim Start eines WebAPI-Projekts im Visual Studio Debugger öffnet sich jetzt automatisch die OAS-Hilfeseite.
Der integrierte Webserver Kestrel unterstützt nun HTTP/2 Ping Frames. Header, die bisher in UTF-8 erwartet wurden, können jetzt auch andere Encodings verwenden. Die Authentifizierung mit Zertifikaten ist beschleunigt.
Runtime und Sprachen
Wie schon in den verschiedenen .NET-Core-Versionen hat Microsoft auch in .NET 5.0 einige Arbeitszeit in die Leistungsoptimierung von Just-in-Time-Compiler, Garbage Collector und Basisklassenbibliothek investiert und meldet deutliche Erfolge.
.NET 5.0 enthält nun die Version 9.0 der Programmiersprache C# mit Records als kompakt deklarierbare, unveränderliche Datenstrukturen, einer verkürzten Schreibweise bei der Instanzierung, Modul-Initialisierungsfunktionen, Erweiterungen beim Pattern Matching und vielen anderen Neuerungen. Microsoft hat 80 Prozent der Klassenbibliotheks-APIs in .NET 5.0 mit Annotationen für die in C# 8.0 eingeführten Nullable Reference Types versehen.
Für Visual Basic .NET-Entwickler liefert Microsoft jetzt zwar auch Projektvorlagen zur Erstellung von WPF- und Windows-Forms-Anwendungen im .NET 5.0 SDK und in Visual Studio 2019 ab Version 16.8 mit, aber alle ASP.NET-Core-basierten Projektarten sind weiterhin nur mit C# und teilweise mit F# möglich (s. Abb. 3).
Zur Problemdiagnose können Entwickler nun auch Dump-Dateien von .NET-Prozessen auf macOS erstellen und Linux-Dumps in Windows auswerten. Mit dem neuen .NET-SDK-basierten Kommandozeilenwerkzeug dotnet-runtimeinfo kann man sich Basisinformationen über das Betriebssystem und die aktuelle .NET-Version liefern lassen.
Verbesserungen beim Veröffentlichen
Bereits seit .NET Core 3.0 können Entwickler beim Befehl dotnet publish mit dem Parameter /p:PublishSingleFile=true erreichen, dass die ausführbare EXE-Datei zusammen mit allen benötigten DLLs (einschließlich .NET-Runtime-Dateien) in eine EXE verpackt wird. Bisher war das aber nicht mehr als ein selbstextrahierendes Archiv, das beim ersten Start mit merklicher Verzögerung in das Temp-Verzeichnis der Benutzer ausgepackt wird. In .NET 5.0 ist der Code direkt aus dem Archiv startbar. Während in Unix-basierten Betriebssystemen tatsächlich eine Datei entsteht, sieht man unter Windows in der Ausgabe von dotnet publish einige zusätzliche native DLLs. Diese kann man mit der Option -p:IncludeNativeLibrariesForSelfExtract=true ebenfalls in die ausführbare Datei verpacken, wobei (wie der Optionsname schon sagt) diese dann beim ersten Start ausgepackt werden.
Für das auch schon in .NET Core 3.0 eingeführte Application Trimming im Rahmen von dotnet publish hat Microsoft in .NET 5.0 den neuen Modus <TrimMode>Link</TrimMode> eingeführt. Im Gegensatz zum bisherigen Vorgehen werden dabei nicht nur ungenutzte .NET-Assemblies, sondern per Tree Shaking auch ungenutzte Typen und einzelne Mitglieder entfernt. Das einige Zeit beanspruchende Trimming schaltet man wie bisher mit <PublishTrimmed>true</PublishTrimmed> ein; <TrimMode> copyused</TrimMode> ist dann weiterhin der Standard.
Außerdem kehrt in .NET 5.0 das Click-Once-Deployment zum Verbreiten und Aktualisieren von .NET-Anwendungen per Webserver und Netzwerklaufwerk zurück. Wie im klassischen .NET Framework kann jeder Windows-Benutzer auch ohne Administratorrechte eine per Click-Once verbreitete Anwendung im lokalen Benutzerverzeichnis installieren und später aktualisieren. Gegenüber dem Original-Click-Once-Deployment in .NET Framework gibt es allerdings Einschränkungen. So sind Programmaktualisierungen nur beim Anwendungsstart, nicht aber beim Beenden oder durch Benutzeraktion im Betrieb möglich.
Das Click-Once-Deployment gehörte ursprünglich zu den Techniken, die Microsoft nicht aus dem .NET Framework in die neue Welt übernehmen wollte. Die Übernahme von Funktionen aus dem klassischen .NET Framework ist offiziell seit dem 14. Oktober 2019 beendet; für das bei Kunden doch sehr beliebte Click-Once-Deployment hat Microsoft jedoch eine Ausnahme gemacht. Es gibt allerdings bisher keine Hinweise darauf, dass auch andere beerdigte Techniken ebenfalls noch zurückkehren werden.
Änderungen bei der Interoperabilität
Eine fundamentale Neuerung in .NET 5.0 ist die Möglichkeit, dass Entwickler nun .NET-Code direkt aus anderen Programmiersprachen auf nativem C/C++-Weg aufrufen können, was die meisten Programmiersprachen beherrschen. Somit sind .NET-5.0-Module nun fast in beliebige Sprachen einbindbar.
Die Interoperabilität zur mit Windows 8 eingeführten Windows Runtime Library (WinRT) ist nicht mehr Teil der .NET-5.0-Laufzeitumgebung, sondern wird durch ein NuGet-Paket angeboten. Das soll aus der Sicht von Microsoft nicht bedeuten, dass WinRT nicht mehr relevant sei. Vielmehr will man die Einwicklung der WinRT-Interoperabilität von der .NET-Versionierung entkoppeln.
Weitere Neuerungen
.NET 5.0 bietet auch Überarbeitungen für den in .NET Core 3.0 neu eingeführten JSON-Serialisierer System.Text.Json. Er kann nun wie sein Vorgänger JSON.NET zirkuläre Referenzen im Objektmodell ignorieren. Zudem gibt es im Namensraum System.Net.Http.Json. neue Erweiterungsmethoden (GetFromJsonAsync(), PostAsJsonAsync(), PutAsJsonAsync() und ReadFromJsonAsync()) für die Serialisierung und Deserialisierung in der Klasse HttpClient.
Die Formatierung von Ausgaben des ConsoleFormatter ist jetzt anpassbar. Ein neuer JSON Console Logger liefert Ausgaben im JSON-Format. Die Bibliothek System.DirectoryServices.Protocols, die die Version 3.0 des Lightweight Directory Access Protocol (LDAP) und die Version 2.0 der Directory Services Markup Language (DSML) realisiert, läuft nun auch auf Linux.
Auch die Steuerelemente des schon vor vielen Jahren totgesagten Windows Forms verbessert der Hersteller weiter. Es gibt ein neues Steuerelement TaskDialog. Beim ListView-Steuerelement können Entwickler nun einzelne Gruppen zusammenklappen. Zudem ist die Unterstützung für Windows-Forms-Anwendungen, die nur einmal laufen dürfen (Single Instance), jetzt auch in der modernen .NET-Welt verfügbar.
Start mit .NET 5.0
Das .NET 5.0 Software Development Kit (SDK) und drei Varianten der Laufzeitumgebung (für Konsolenanwendungen, für Desktop-Anwendungen und Web) liefert Microsoft kostenfrei und ohne Registrierung über die Website. SDK und Runtime installieren sich parallel zu vorhandenen Versionen von .NET Core und .NET Framework. Der Kommandozeilenbefehl dotnet –version gibt Auskunft über die im aktuellen Verzeichnis aktive SDK-Version.
Für die .NET 5.0-Entwicklung notwendig ist Visual Studio 2019 Version 16.8, das ebenfalls heute die Preview-Phase verlassen hat. Eine Entwicklung mit einer aktuellen Version von Visual Studio Code und zur Projektart passenden Erweiterungen ist ebenfalls möglich. Die Firma Jet Brains will volle Unterstützung für .NET 5.0 erst in die kommende Version 2020.3 integrieren.
Fazit
Auch ohne die verschobene Vereinheitlichung hat .NET 5.0 einige Verbesserungen zu bieten, die Entwicklern als Anreiz dienen können, auf .NET 5.0 umzusteigen. Der Umstieg von .NET Core 3.x auf .NET 5.0 ist problemlos. Im Gegensatz zum Versionswechsel von .NET Core 2.x auf 3.x gibt es dieses Mal nur sehr wenige Breaking Changes.
Der Weg von klassischem .NET Framework 4.x auf .NET 5.0 ist auch nach den Verbesserungen in .NET 5.0 weiterhin ein nicht zu unterschätzender Aufwand, dessen Größe stark von der Anwendungsart, der eingesetzten Softwarearchitektur und dem Programmierstil abhängt. Grundsätzlich zeigt die Erfahrung des Autors von vielen bereits erfolgten Migrationen, dass sich 2-Tier-Desktop-Anwendungen deutlich einfacher umstellen lassen als N-Tier-Anwendungen und Webanwendungen. Das liegt insbesondere daran, dass einige in diesen Bereichen häufig eingesetzte Techniken wie Windows Communication Foundation (WCF) und ASP.NET Webforms in .NET 5.0 nicht mehr vorhanden sind beziehungswesie es deutliche Unterschiede zwischen dem alten ASP.NET MVC und ASP.NET WebAPI und dem neuen ASP.NET Core MVC und ASP.NET Core WebAPI gibt.
Dr. Holger Schwichtenberg
ist Chief Technology Expert bei der MAXIMAGO-Softwareentwicklung. Mit dem Expertenteam bei www.IT-Visions.de bietet er zudem Beratung und Schulungen im Umfeld von Microsoft-, Java- und Web-Techniken an. Er ist Autor zahlreicher Bücher, u.a. "ASP.NET Core Blazor: Moderne Single-Page-Web-Applications mit .NET, C# und Visual Studio".
(ane)
