Reif für die Produktion: Erster Release Candidate von .NET 6
Mit der RC1-Version unterstützt Microsoft den Einsatz der kommenden .NET-Version 6 im produktiven Betrieb – ausgenommen sind Cross-Plattform Apps mit MAUI.
(Bild: Dmytro Mikriukov / Shutterstock.com)
- Dr. Holger Schwichtenberg
Nach insgesamt sieben Previews ist die gestern erschienene Version die erste von zwei Release-Candidate-Veröffentlichungen von .NET 6. Sie bietet nicht nur eine Stabilisierung einiger zuvor bereits veröffentlichten Funktionen wie Hot Reloading, sondern auch zahlreiche neue Funktionen für Webentwickler.
Während .NET 6 einschließlich ASP.NET Core 6.0 und Entity Framework Core 6.0 in der RC1-Version von Microsoft eine "Go-Live"-Lizenz erhalten, die zum produktiven Einsatz berechtigt, ist die Entwicklung von Cross-Plattform-Anwendungen mit .NET Multi-Platform App UI (.NET MAUI) für Android, iOS, macOS und Windows davon ausdrücklich ausgenommen. Scott Hunter erklärt in einem Blogeintrag, dass man auch bis zum angekündigten .NET 6-Veröffentlichungstermin am 9. November 2021 keinen vollständigen Zustand erreichen werde und daher das Erscheinen dieser Anwendungsart auf das zweite Quartal 2022 vertagt habe. Immerhin ist die Installation von .NET MAUI nun direkt über Visual Studio 2022 möglich, das parallel als Preview 4 erschienen ist. Mit Live Preview sehen Entwicklerinnen und Entwickler den aktuellen Anwendungsstatus.
Blazor in JavaScript-Apps
Bei dem in .NET 6 enthaltenen Webframework Blazor 6.0 fokussiert die RC1-Version auf erweiterte Interoperabilitätsszenarien zwischen C# und JavaScript. Zur Integration von Blazor in bestehenden JavaScript-Anwendungen ist es nun möglich, einzelne Blazor-Komponenten aus JavaScript-Code zu rendern. Auf dieser Basis zeigt ein Beispiel auf GitHub die Nutzung von Blazor in Angular- und React-basierten Single Page Apps. Microsoft arbeitet auch daran, Blazor-Komponenten als Standard Web Components bereitzustellen. Das zum Erstellen von HTML Custom Elements bereitliegende NuGet-Paket Microsoft.AspNetCore.Components.CustomElements ist aber erst im experimentellen Alpha-Stadium.
Per JavaScript Initializer kann ein Entwickler nun vor und nach dem Laden von Blazor-Anwendungen und Razor Class Libraries JavaScript-Code ausführen. Nachdem in Preview 7 das schnelle Daten-Streaming von JavaScript zu C# bereitgestellt wurde, bietet RC1 nun auch den umgekehrten Weg von C# zu JavaScript mit der .NET-Klasse DotNetStreamReference; in JavaScript gehen die Daten als Array Buffer oder Readable Stream ein. JavaScript-Dateien, die bisher immer im wwwroot-Ordner liegen mussten, lassen sich in Blazor 6 direkt zu Razor-Dateien zuordnen, indem sie die Dateinamenerweiterung .razor.js beziehungsweise .cshtml.js erhalten.
Die Klasse NavigationManager unterstützt mit GetUriWithQueryParameter() und GetUriWithQueryParameters() zwei neue Methoden für die Bearbeitung von Querystrings. Im Ereignisparametertyp MouseEventArgs gibt es nun die Werte PageX und PageY.
Alternativ zu Websockets ist bei Blazor Server seit der ersten Version die kontinuierliche Browser-Server-Kommunikation auch per HTTP Long Polling möglich. Microsoft hat den automatischen Rückfall auf diese Strategie in Blazor Server 6.0 deaktiviert, damit nicht versehentlich Long Polling zum Einsatz kommt. Für Blazor WebAssembly, dessen DLL-Ladevorgänge bisher von einigen Firewalls und Sicherheitsanwendungen blockiert wurde, bietet Blazor 6.0 nun einen anpassbaren Ladevorgang an. Details dazu will Microsoft laut Blogeintrag demnächst erst verraten.
Bereits in der aktuellen Ankündigung benannt sind eine Reihe von Verbesserungen für OpenAPI, Parameterbindung und Fehlerbehandlung für die neue, vereinfachte WebAPI-Programmierung. Auch die Einrichtung von HTTP/3 ist einfacher.
Temporale Tabellen
Microsofts ORM-Mapper Entity Framework Core unterstützt in der Version 6 RC1 nun temporale Datenbanktabellen, die die Historie der Werte in Datensätze speichern. Eine temporale Tabelle definiert man mit dem Zusatz IsTemporal() im Fluent API. Die Abfrage erfolgt dann mit den neuen Operatoren TemporalAsOf(), TemporalAll(), TemporalBetween(), TemporalFromTo() und TemporalContainedIn(). Die Unterstützung für temporale Tabellen gilt für alle relationalen Datenbanken. Microsoft selbst bietet das Feature für seinen SQL Server. Andere Datenbankhersteller können es in ihre Treiber einbauen.
Am 23. November 2021 richten heise Developer und dpunkt.verlag in Kooperation mit www.IT-Visions.de mit der betterCode() .NET 6 eine Online-Konferenz zum kommenden LTS-Release (Long-Term Support) von Microsofts Entwicklungsplattform .NET aus. Sie soll im November erscheinen und ist die neue Basis für alle auf Microsofts Entwicklungsplattform aufbauenden Programme – ob Desktop-Applikationen mit Windows Forms und WPF, Webanwendungen mit ASP.NET, mobile Apps auf Basis von Universal Windows Platform und .NET MAUI oder Unity-Spiele. Tickets und weitere Informationen zum Programm der betterCode() .NET 6 bietet die Konferenzwebseite.
Beim Reverse Engineering von Datenbanken mit reinen N:M-Zwischentabellen generiert das PowerShell-Commandlet Scaffold-DbContext nun keine Klassen mehr für die Zwischentabellen und baut stattdessen zwei Direktbeziehungen mit ICollection<T>. Das Feature gibt es grundsätzlich schon seit Version 5.0, es wurde aber beim Reverse Engineering bisher nicht ausgenutzt. Auch dieses Mal hat das Entwicklungsteam einige geplante Funktionen wie die Unterstützung von JSON-Spaltentypen gestrichen.
Bei den impliziten Namensräumen, die Preview 7 automatisch per Global Using (ein C# 10-Feature) in alle .NET 6-Projekte importiert hatte, vollzieht Microsoft eine Kehrtwende. Dieser Automatismus führte zu Problemen beim Aktualisieren von Programmcode, der gleichnamige Klassen in anderen Namensräumen verwendete. Die impliziten Namensräume sind ab RC1 nur noch aktiv, wenn in der .csproj-Projektdatei in einer <PropertyGroup> explizit das Tag <ImplicitUsings>enable</ImplicitUsings> vorkommt. Dies ist nur bei mit .NET 6 in Visual Studio 2022 neu angelegten C#-Projekten der Fall; ältere Projekte, die auf .NET 6 hochgestuft werden, erhalten das Tag nicht. In neuen Projekten können C#-Entwicklerinnen und -Entwickler die impliziten Namensräume durch Löschen des Tags respektive mit <ImplicitUsings>disable</ImplicitUsings> deaktivieren. Alternativ kann man auch einzelne Namensräume in einer <ItemGroup> mit <Using Remove="Namensraum"> deaktivieren.
(map)