.NET 5.0 RC2 mit neuen Features und neuen Schwächen
Der zweite Release Candidate von .NET 5.0 zeigt noch eine Reihe von Unzulänglichkeiten.
- Dr. Holger Schwichtenberg
Genau einen Monat nach dem ersten Release Candidate (RC1) ist nun die zweite RC-Version erschienen, die .NET 5.0 auf die Zielgerade bringen soll. Alle neuen Features wollte Microsoft eigentlich schon seit August 2020 im Produkt haben. Aber die gestern veröffentlichte RC2-Version (zusammen mit Visual Studio 2019 v16.8 Preview 4) präsentiert noch weitere Neuerungen. Allen voran ist dies die Rückkehr des Click-Once-Deployment.
Click-Once-Deployment kehrt zurück
Click-Once-Deployment ist ein Verfahren zur Verbreitung von .NET-Anwendungen, das es seit .NET Framework 2.0 gibt. Es erlaubt die einfache Verteilung und automatische Aktualisierung von Windows-Anwendungen über Webserver und Netzwerklaufwerke. Die Installation ist ohne Administratorenrechte möglich und erfolgt im lokalen Benutzerverzeichnis.
In .NET Core 1.0 bis 3.1 war das Click-Once-Deployment trotzt gegenteiliger Ankündigung von Microsoft nicht enthalten und galt daher als "gestorbene" Technik. Im Juli 2020 tauchte auf GitHub der Hinweis auf, das Verfahren solle in .NET 5.0 zurückkehren – allerdings in eingeschränkter Form, d.h. Programmaktualisierungen sind nur beim Anwendungsstart, nicht aber beim Beenden oder durch Benutzeraktion im Betrieb möglich.
Laut dem Blogeintrag zur Ankündigung von .NET 5.0 RC2 soll Click-Once-Deployment nun doch möglich sein. Ein Schnelltest ergab, dass das Kommandozeilenwerkzeug mage.dot zwar auf NuGet.org verfügbar ist, aber nicht wie beschrieben arbeitet. Die gezeigten Befehle führen zum Absturz des Werkzeugs mit dem Hinweis: "Internal error, please try again. Object reference not set to an instance of an object".
Auch die im Blog gezeigte Funktion zum Konfigurieren in Visual Studio findet sich weder in der gestern erschienenen Version 16.8.0 Preview 4.0 noch in deren Release Notes. Entwickler werden wohl noch auf ein weiteres Update von Visual Studio warten müssen.
Verbesserungen für Blazor mit Schwächen
Weitere Neuerungen findet man in RC2 für ASP.NET Core Blazor. Die in RC1 im September 2020 eingeführte Möglichkeit der isolierten CSS-Dateien pro Razor Component sammelt nun die Styles nicht mehr aus allen beteiligten Projekten in eine einzige CSS-Datei (_framework/scoped.styles.css) sondern erzeugt getrennte CSS-Dateien pro Projekt (Projektname.styles.css). Für das Nachladen von JavaScript-Dateien verwendet Microsoft nun die Schnittstelle IJSObjectReference anstelle der Klasse JSObjectReference.
Laut Blogeintrag zu ASP.NET Core 5.0 RC2 hat Microsoft nun Klassen und Klassenmitglieder aus der .NET-Klassenbibliothek annotiert, die in Blazor WebAssembly-Anwendungen nicht verfügbar sind, sodass Visual Studio den Code für Entwickler als Warnung unterschlängelt. Der Schnelltest ergab, dass dies tatsächlich mit dem Befehl Console.ReadLine() funktioniert. Bei anderen im Browser nicht erlaubten Operationen (z.B. Thread.Start(), new SqlConnection() und AppDomain.CreateDomain()) erhalten Entwickler aber keinerlei Warnung, sondern nur einen Laufzeitfehler vom Typ System.PlatformNotSupportedException.
In RC1 war das Debugging von Blazor WebAssembly aufgrund eines Bugs nicht möglich. Den Fehler will Microsoft nun behoben und zudem inhaltliche Verbesserungen eingebaut haben, z.B. die Anzeige von Werten auch für vererbte Mitglieder, Nullable Value Types, für Boxed Values und im Falle von Reflection.
Im Test mit .NET 5.0 RC2 und Preview 4 von Visual Studio 2019 v16.8 funktioniert das Debugging aber weiterhin gar nicht: Haltepunkte werden einfach ignoriert, sowohl in der Projektvorlage von Microsoft als auch in realen Blazor-Projekten. Auch die IntelliSense-Eingabeunterstützung für Blazor WebAssembly stürzt in dieser Version regelmäßig mit dem Fehler "RemoteInvocationExecption" ab (siehe Abbildung).
Weitere Änderungen
In Visual Studio 2019 v16.8 Preview 4 finden Entwickler nun schon im Dialog "Add a new Project" getrennte Projektvorlagen für Blazor Server und Blazor WebAssembly.
Nicht im Blogeintrag zu ASP.NET Core Blazor 5.0 RC2 erwähnt ist, dass Anwendungen, die dem Benutzer zur Laufzeit einen Wechsel der Sprache anbieten, nun in der Projektdatei einen Eintrag <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData> erfordern.
Die Ankündigung zu .NET 5.0 RC2 verschweigt zudem einen zentralen Breaking Change für Desktop-Anwendungen mit Windows Forms und Windows Presentation Foundation (WPF): Der sogenannte Target Framework Moniker muss in allen Projekten von <TargetFramework>net5.0</TargetFramework> auf <TargetFramework>net5.0-windows</TargetFramework> geändert werden. Dies hatte Microsoft zwar schon vor Monaten auf GitHub verkündet und auch in die Dokumentation eingebaut, aber bisher noch die einfache Angabe erlaubt.
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
Ausblick
Ursprünglich sollte .NET 5.0 schon am Ende der Preview-Phase "Feature Complete" sein und die Release-Candidate-Phase sollte dem Bugfixing und Feinschliff dienen. Nun hat Microsoft aber in RC1 und RC2 noch einige neue Funktionen integriert, die allerdings schlecht beziehungsweise gar nicht funktionieren.
Bis zur finalen Version, die in weniger als vier Wochen am 10. November 2020 im Rahmen der virtuellen .NET Conf 2020 erscheinen soll, haben die Entwicklungsteams bei Microsoft noch einiges zu tun, damit es in .NET 5.0 nicht so viele Fehler wie in .NET Core 3.0 gibt (erschienen im September 2019), die dann erst mit späteren Updates behoben wurden.
(map)
