.NET 8.0 Preview 5, 6 und 7 – Teil 2

Auf hohem Sprachniveau

Auf hohem Sprachniveau

.NET 8.0 Preview 5, 6 und 7 – Teil 2

Auf hohem Sprachniveau


Mit den Previews Nummer 5, 6 und 7 von .NET 8.0 realisiert Microsoft schrittweise die Blazor-United-Versprechungen. Darüber hinaus gibt es neue Sprachfeatures für C# 12.0 sowie Verbesserungen beim AOT-Compiler, bei ASP.NET Core, bei .NET MAUI und sogar ein neues Steuerelement für WPF – die restlichen Änderungen.

Ich berichtete in Windows Developer bereits über vorherige Vorschauversionen von .NET 8.0:

  • über die Previews 1 und 2 in Ausgabe 6.2023 sowie

  • über die Previews 3 und 4 in Ausgabe 8.2023.

Bis zum Redaktionsschluss für die Ausgabe, die Sie nun in den Händen halten, sind noch Preview 5 (13. Juni 2023), Preview 6 (11. Juli 2023) und Preview 7 (8. August 2023) erschienen.

Als geplanter Erscheinungstermin für die fertige Version von .NET 8.0 wurde inzwischen der 14. November 2023 verkündet. Bis dahin wird es noch zwei weitere Vorschauversionen mit dem Titel „Release Candidate“ geben. Üblich ist, dass Microsoft mit den Release-Candidate-Versionen eine Go-live-Lizenz verbindet, das heißt ab dann ist der produktive Einsatz von .NET 8.0 erlaubt. Das heißt aber nicht, dass es in der Release-Candidate-Phase keine Änderungen mehr geben wird.

Über einen Teil der umfangreichen Änderungen habe ich Sie bereits in der vorherigen Ausgabe des Windows Developers informiert; die Besprechung der übrigen Features folgt nun.

Globale kaskadierende Blazor-Werte

Kaskadierende Werte, die man bisher nur in Razor-Komponenten definieren konnte, können Entwicklerinnen und Entwickler in .NET 8.0 im Startcode einer Blazor-Anwendung innerhalb der Program.cs registrieren, um diese Werte als Zustand für alle Komponenten in einer Komponente verfügbar zu machen. Dazu registriert man ein Objekt wahlweise ohne expliziten Namen:

builder.Services.AddCascadingValue(sp => new Autor { Name = "Dr. Holger Schwichtenberg1", Url = "www.dotnet-doktor.de" });

oder mit Namen:

builder.Services.AddCascadingValue("autor2", sp => new Autor { Name = "Dr. Holger Schwichtenberg", Url = "www.dotnet-doktor.de" });

oder via CascadingValueSource:

builder.Services.AddCascadingValue(sp =>
  {
    var a = new Autor { Name = "Holger Schwichtenberg", Url = "www.dotnet-doktor.de" };
    var source = new CascadingValueSource<Autor>("autor3",a, isFixed: false);
    return source;
});

Dann kann jede Razor-Komponente innerhalb der Blazor-Anwendung dieses Objekt konsumieren und auch verändern (Listing 1).

Listing 1

@code
{
  [CascadingParameter]
  Autor autor1 { get; set; }
  
  [CascadingParameter(Name = "autor2")]
  Autor autor2 { get; set; }
  
  [CascadingParameter(Name = "autor3")]
  Autor autor3 { get; set; }
  
  [ParameterAttribute]
  public int id { get; set; }
  
  protected override void OnInitialized()
  {
    autor3.Name = "Dr. " + autor3.Name;
  }
}

Antiforgery-Token zum Schutz gegen Cross-Site Request Forgery

Für den Schutz gegen Angriffe nach dem Prinzip der Cross-Site Request Forgery (CSRF/XSRF) liefert Microsoft in ASP.NET Core 8.0 ab Preview 7 eine neue Middleware, die Entwicklerinnen und Entwickler im Startcode einer ASP.NET-Core-Anwendung via builder.Services.AddAntiforgery(); integrieren können. Dieser Aufruf aktiviert zunächst nur in der Verarbeitungs-Pipeline das IAntiforgeryValidationFeature. Ein auf ASP.NET Core aufbauendes Webframework (z. B. Blazor, WebAPI, MVC, Razor Pages) muss sodann ein Antiforgery-Token im Programmcode berücksichtigen. Der Blogeintrag [1] zeigt Implementierungsbeispiele für ASP.NET Core Minimal APIs [2] und Blazor (bei Verwendung von <EditForm>) [3], lässt aber offen, wie der Implementierungsstatus für andere ASP.NET-Core-basierte Webframeworks wie MVC und Razor Pages ist.

WebCIL ist nun der Standard bei Blazor WebAssembly

Seit .NET 8.0 Preview 4 gibt es das WebCIL-Format für Blazor WebAssembly; seit Preview 7 ist es nun im Standard aktiv. Die Implementierung von WebCIL zusammen mit WebAssembly-Modulen zielt darauf ab, die Blockierung von Blazor WebAssembly durch Firewalls und Antivirensoftware zu verhindern. Microsoft hat das Format inzwischen so angepasst, dass Standard-WebAssembly-Module mit der Dateinamenserweiterung .wasm generiert werden (in Preview 4 war es noch .webcil).

Entwicklerinnen und Entwickler haben die Option, WebCIL zu deaktivieren, indem man den Schalter <WasmEnableWebcil>false</Wasm-EnableWebcil> in der Projektdatei verwendet. Im Blogeintrag [4] gibt Microsoft jedoch keine expliziten Hinweise darauf, in welchen Szenarien das sinnvoll sein könnte. Bisher waren die Blazor-WebAssembly-Dateien standardmäßig mit der Erweiterung .dll versehen.

Identity Server ist raus

Gemäß der Ankündigung auf der Build-Konferenz im Mai 2023 hat Microsoft den Duende Identity Server nun aus seinen Projektvorlagen für React- und Angular-Projekte mit einem ASP.NET-Core-Backend entfernt. Dieser Schritt wurde vom .NET-Entwicklungsteam unternommen, da der Identity Server, der in den Versionen 1 bis 4 als Open-Source-Software und Projekt der gemeinnützigen .NET Foundation verfügbar war, mittlerweile zu einem kommerziellen Produkt geworden ist. Ausgenommen von den Lizenzgebühren sind lediglich Open-Source-Projekte. Microsoft hat sich entschieden, die besagten Projektvorlagen nun auf das in ASP.NET Core integrierte Identity-System zu stützen. Für Entwicklerinnen und Entwickler, die den Identity Server weiterhin nutzen möchten, stellt Microsoft die Dokumentation von Duende zur Verfügung [5].

Weitere WebAPIs für ASP.NET Core Identity

In .NET 8.0 Preview 4 hatte Microsoft für ASP.NET Core Identity, das integrierte Benutzerverwaltungssystem von ASP.NET Core, erstmals WebAPI-Endpunkte eingeführt. Diese Ergänzung erfolgte neben der bereits vorhandenen Weboberfläche, die auf serverseitigem Rendering basiert. Dies geschah, um ASP.NET Core Identity effektiver in Single-Page-Webanwendungen (unter Verwendung von JavaScript oder Blazor) zu integrieren. Zuvor beschränkten sich die verfügbaren WebAPI-Endpunkte lediglich auf die Benutzerregistrierung (/register) und die Benutzeranmeldung (/login).

In Preview-Version 7 wurden weitere Endpunkte hinzugefügt. Diese umfassen die Bestätigung von Benutzerkonten per E-Mail (/confirmEmail und / resendConfirmationEmail), das Zurücksetzen von Passwörtern (/resetPassword), die Aktualisierung von Tokens (/refresh) sowie die Unterstützung für die 2-Faktor-Authentifizierung (/account/2fa) sowie das Lesen und Aktualisieren von Profildaten (/account/ info).

Die Aktivierung dieser WebAPI-Endpunkte für ASP. NET Core Identity erfolgt in der Program.cs, indem nach AddIdentityCore<T>() die Funktion AddApiEndpoints() aufgerufen wird, wie in Listing 2 dargestellt.

Listing 2: Startcode einer ASP.NET-Core-Anwendung, die eine Benutzerverwaltung via ASP.NET Core Identity via WebAPI bereitstellt (Quelle: [1])

using System.Security.Claims;
using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;
 
var builder = WebApplication.CreateBuilder(args);
 
builder.Services.AddAuthentication().AddBearerToken(IdentityConstants.BearerScheme);
builder.Services.AddAuthorizationBuilder...