Freigeben über

Neuerungen in ASP.NET Core in .NET 11

In diesem Artikel werden die wichtigsten Änderungen in ASP.NET Core in .NET 11 mit Links zu relevanten Dokumentationen erläutert.

Dieser Artikel wird aktualisiert, wenn neue Vorschauversionen verfügbar gemacht werden.

Blazor

In diesem Abschnitt werden neue Features für Blazorbeschrieben.

Neue DisplayName Komponente und Unterstützung für [Display] und [DisplayName] Attribute

Die DisplayName Komponente kann verwendet werden, um Eigenschaftennamen aus Metadatenattributen anzuzeigen:

[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }

Das [Display] Attribut für die Modellklasseneigenschaft wird unterstützt:

[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }

Von den beiden Ansätzen wird das [Display] Attribut empfohlen, wodurch zusätzliche Eigenschaften zur Verfügung gestellt werden. Das [Display] Attribut ermöglicht auch das Zuweisen eines Ressourcentyps für die Lokalisierung. Wenn beide Attribute vorhanden sind, hat [Display] Vorrang vor [DisplayName]. Wenn kein Attribut vorhanden ist, greift die Komponente auf den Eigenschaftennamen zurück.

Verwenden Sie die DisplayName Komponente in Beschriftungen oder Tabellenüberschriften:

<label>
    <DisplayName For="@(() => Model!.ProductionDate)" />
    <InputDate @bind-Value="Model!.ProductionDate" />
</label>

Blazor Webskript-Startoptionenformat jetzt unterstützt für Blazor Server und Blazor WebAssembly Skripts

Das Optionsobjekt Blazor Web App Skript (blazor.web.js), das an Blazor.start() übergeben wird, verwendet seit der Veröffentlichung von .NET 8 das folgende Format:

Blazor.start({
  ssr: { ... },
  circuit: { ... },
  webAssembly: { ... },
});

Blazor Server Jetzt können (blazor.server.js) und Blazor WebAssembly (blazor.webassembly.js) Skripts dasselbe Optionsformat verwenden.

Das folgende Beispiel zeigt das format der vorherigen Optionen, das weiterhin unterstützt wird:

Blazor.start({
  loadBootResource: function (...) {
      ...
    },
  });

Das neu unterstützte Optionsformat für das vorherige Beispiel:

Blazor.start({
  webAssembly: {
    loadBootResource: function (...) {
      ...
    },
  },
});

Weitere Informationen finden Sie unter Starten von ASP.NET CoreBlazor.

Neue BasePath-Komponente

Blazor Web Apps können die neue BasePath Komponente (<BasePath />) verwenden, um den App-Basispfad (<base href>) HTML-Tag automatisch zu rendern. Weitere Informationen finden Sie unter ASP.NET Core-App-BasispfadBlazor.

Inline-Ereignishandler JS aus der NavMenu Komponente entfernt

Der Inline-Ereignishandler JS, der die Anzeige von Navigationslinks umschaltet, ist in der Komponente NavMenu der Projektvorlage Blazor Web App nicht mehr vorhanden. Apps, die aus der Projektvorlage generiert wurden, verwenden jetzt einen verbundbasierten JS Modulansatz , um die Navigationsleiste auf der gerenderten Seite ein- oder auszublenden. Der neue Ansatz verbessert die Compliance von Inhaltssicherheitsrichtlinien (Content Security Policy, CSP), da der CSP keinen unsicheren Hash für die Inline JSenthält.

Informationen zum Migrieren einer vorhandenen App zu .NET 11, einschließlich der Einführung des neuen JS Modulansatzes für den Navigationsleisten-Toggler, finden Sie unter Migrieren von ASP.NET Core in .NET 10 zu ASP.NET Core in .NET 11.

Der neue RelativeToCurrentUri Parameter (Standard: false) für NavigationManager.NavigateTo und die NavLink Komponente ermöglicht es Ihnen, zu URIs relativ zum aktuellen Seitenpfad zu navigieren, anstatt zum Basis-URI der App.

Betrachten Sie die folgenden geschachtelten Endpunkte:

  • /docs
    • /getting-started
      • /installation
      • /configuration

Wenn der URI des Browsers /docs/getting-started/installation ist und Sie den Benutzer zu /docs/getting-started/configuration navigieren möchten, wird NavigateTo("/configuration") am Stamm der App bei /configuration umgeleitet, anstatt zum relativen Pfad bei /docs/getting-started/configuration. Legen Sie das RelativeToCurrentUri mit NavigateTo oder die NavLink Komponente für die gewünschte Navigation fest:

Navigation.NavigateTo("/configuration", new NavigationOptions
{
    RelativeToCurrentUri = true
});

<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>

Speichern temporärer Daten zwischen HTTP-Anforderungen während des statischen serverseitigen Renderings (statischer SSR)

Um temporäre Daten zwischen HTTP-Anforderungen während des statischen serverseitigen Renderings (static SSR) zu sichern, unterstützt Blazor TempData. TempData eignet sich ideal für Szenarien wie Flashnachrichten nach Formularübermittlungen, Übergeben von Daten während umleitungen (POST-Redirect-GET Muster) und einmalige Benachrichtigungen.

TempData ist verfügbar, wenn AddRazorComponents in der App-Datei Program aufgerufen wird und als kaskadierender Wert mit dem [CascadingParameter] Attribut bereitgestellt wird.

[CascadingParameter]
public ITempData? TempData { get; set; }

Weitere Informationen finden Sie unter ASP.NET Core Blazor serverseitige Zustandsverwaltung.

Neue Web Worker-Vorlage (webworker)

Blazor WebAssembly Apps können auf dem Client eine schwere Berechnung durchführen. Dies beeinträchtigt jedoch im UI-Thread das Rendern der Benutzeroberfläche und wirkt sich negativ auf die Benutzeroberfläche aus. In .NET 10 haben wir einen Artikel mit einer Beispiel-App hinzugefügt, um das Entladen von schweren Arbeiten aus dem UI-Thread zu einem Web Worker zu vereinfachen. Für .NET 11 haben wir die .NET Web Worker-Projektvorlage (webworker) hinzugefügt, die Infrastruktur zum Ausführen von .NET-Code in einem Web Worker bereitstellt. Weitere Informationen finden Sie unter ASP.NET Core Blazor mit .NET on Web Workers.

Blazor Hybrid

In diesem Abschnitt werden neue Features für Blazor Hybridbeschrieben.

Versionshinweise erscheinen in diesem Abschnitt, wenn Vorschaufunktionen verfügbar werden.

SignalR

In diesem Abschnitt werden neue Features für SignalRbeschrieben.

Minimale APIs

In diesem Abschnitt werden neue Features für minimale APIs beschrieben.

OpenAPI

In diesem Abschnitt werden neue Features für OpenAPI beschrieben.

Beschreiben Sie Binärdateiantworten

ASP.NET Core 11 bietet Unterstützung für das Generieren von OpenAPI-Beschreibungen für Vorgänge, die Binäre Dateiantworten zurückgeben. Diese Unterstützung ordnet den FileContentResult Ergebnistyp einem OpenAPI-Schema mit type: string und format: binary zu.

Verwenden Sie die Produces<T>-Erweiterungsmethode mit T von FileContentResult, um den Antworttyp und den Inhaltstyp anzugeben.

app.MapPost("/filecontentresult", () =>
{
    var content = "This endpoint returns a FileContentResult!"u8.ToArray();
    return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);

Das generierte OpenAPI-Dokument beschreibt die Endpunktantwort wie:

responses:
  '200':
    description: OK
    content:
      application/octet-stream:
        schema:
          $ref: '#/components/schemas/FileContentResult'

Dies FileContentResult ist definiert in components/schemas :

components:
  schemas:
    FileContentResult:
      type: string
      format: binary

OpenAPI 3.2.0-Unterstützung (Breaking Change)

Microsoft.AspNetCore.OpenApi unterstützt jetzt OpenAPI 3.2.0 über eine aktualisierte Abhängigkeit von Microsoft.OpenApi 3.3.1. Dieses Update enthält grundlegende Änderungen aus der zugrunde liegenden Bibliothek. Weitere Informationen finden Sie im Microsoft.OpenApi-Upgradehandbuch.

Um ein OpenAPI 3.2.0-Dokument zu generieren, geben Sie die Version beim Aufrufen AddOpenApian:

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});

Nachfolgende Updates nutzen neue Funktionen in der Spezifikation 3.2.0, z. B. die Elementschemaunterstützung für Streamingereignisse.

Vielen Dank @baywet für diesen Beitrag!

Authentifizierung und Autorisierung

In diesem Abschnitt werden neue Features für Authentifizierung und Autorisierung beschrieben.

TimeProvider Unterstützung in ASP.NET Core Identity

ASP.NET Core Identity verwendet jetzt TimeProvider anstelle von DateTime und DateTimeOffset für alle zeitbezogenen Vorgänge. Diese Änderung macht Identity Komponenten testfähiger und bietet eine bessere Kontrolle über die Zeit in Tests und spezialisierten Szenarien.

Das folgende Beispiel zeigt, wie Sie eine Fälschung TimeProvider zum Testen Identity von Features verwenden:

// In tests
var fakeTimeProvider = new FakeTimeProvider(
    new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));

services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();

// Identity will now use the fake time provider

Mithilfe von TimeProvider können Sie deterministische Tests für zeitkritische Identity Funktionen wie Tokenablauf, Sperrdauern und Sicherheitsstempelüberprüfung einfacher schreiben.

Den Anzeigenamen des Passkeys vom Authentifikator ableiten

ASP.NET Core Identity erzeugt nun automatisch benutzerfreundliche Anzeigenamen für Passkeys basierend auf ihrer AAGUID (Authenticator Attestation GUID). Integrierte Zuordnungen sind für die am häufigsten verwendeten Passkey-Authentifikatoren enthalten, einschließlich Google Password Manager, iCloud-Schlüsselbund, Windows Hello, 1Password und Bitwarden.

Bei bekannten Authentifikatoren wird der Name automatisch zugewiesen, ohne den Benutzer aufzufordern. Bei unbekannten Authentifikatoren wird der Benutzer zu einer Umbenennungsseite umgeleitet. Erweitern Sie die Zuordnungen, indem Sie Einträge zum PasskeyAuthenticators Wörterbuch des Projekts hinzufügen.

Miscellaneous

In diesem Abschnitt werden verschiedene neue Features in .NET 11 beschrieben.

IOutputCachePolicyProvider-Schnittstelle

ASP.NET Core in .NET 11 stellt die [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)' Schnittstelle für die Implementierung benutzerdefinierter Ausgabezwischenspeicherungsrichtlinienauswahllogik bereit. Mithilfe dieser Schnittstelle können Apps die Standardrichtlinie für die Basiszwischenspeicherung ermitteln, das Vorhandensein benannter Richtlinien überprüfen und erweiterte Szenarien unterstützen, in denen Richtlinien dynamisch aufgelöst werden müssen. Beispiele hierfür sind das Laden von Richtlinien aus externen Konfigurationsquellen, Datenbanken oder das Anwenden mandantenspezifischer Zwischenspeicherungsregeln.

Der folgende Code zeigt die IOutputCachePolicyProvider Schnittstelle:

public interface IOutputCachePolicyProvider
{
    IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
    ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}

Vielen Dank @lqlive für diesen Beitrag!

Automatisch vertrauenswürdige Entwicklungszertifikate in WSL

Die Konfiguration des Entwicklungszertifikats vertraut jetzt automatisch Zertifikaten in WSL-Umgebungen (Windows-Subsystem für Linux). Wenn Sie dotnet dev-certs https --trust in WSL ausführen, wird das Zertifikat automatisch installiert und sowohl in der WSL-Umgebung als auch in Windows vertrauenswürdig gemacht, sodass keine manuelle Vertrauenskonfiguration erforderlich ist.

# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust

Diese Verbesserung optimiert die Entwicklungserfahrung bei der Verwendung von WSL und entfernt einen gemeinsamen Reibungspunkt für Entwickler, die in Linux-Umgebungen unter Windows arbeiten.

Vielen Dank @StickFun für diesen Beitrag!

Native OpenTelemetry-Tracing für ASP.NET Core

ASP.NET Core fügt jetzt native OpenTelemetry-Semantikkonventionsattribute zur HTTP-Serveraktivität hinzu, die an der OpenTelemetry-HTTP-Serverspannespezifikation ausgerichtet ist. Alle erforderlichen Attribute sind standardmäßig enthalten und entsprechen den zuvor nur über die OpenTelemetry.Instrumentation.AspNetCore Bibliothek verfügbaren Metadaten.

Um die integrierten Tracing-Daten zu sammeln, abonnieren Sie die Microsoft.AspNetCore-Aktivitätsquelle in Ihrer OpenTelemetry-Konfiguration.

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("Microsoft.AspNetCore")
        .AddConsoleExporter());

Es ist keine zusätzliche Instrumentierungsbibliothek (wie OpenTelemetry.Instrumentation.AspNetCore) erforderlich. Das Framework füllt nun direkt semantische Konventionsattribute in der Anforderungsaktivität aus, wie z. B. http.request.method, url.path, http.response.status_code und server.address.

Wenn der Aktivität keine OpenTelemetry-Attribute hinzugefügt werden sollen, können Sie dies deaktivieren, indem Sie den AppContext-Schalter auf Microsoft.AspNetCore.Hosting.SuppressActivityOpenTelemetryData setzen.

Leistungsverbesserungen

KestrelDer HTTP/1.1-Anforderungsparser verwendet jetzt einen Codepfad ohne Ausnahmen zur Behandlung fehlerhaft formatierter Anforderungen. Anstatt auf jeden Analysefehler zurückzuwerfen BadHttpRequestException , gibt der Parser eine Ergebnisstruktur zurück, die erfolg-, unvollständige oder Fehlerzustände angibt. In Szenarien mit vielen falsch formatierten Anforderungen – z. B. Portüberprüfung, böswilliger Datenverkehr oder falsch konfigurierten Clients – beseitigt dies teure Ausnahmebehandlungsaufwand und verbessert den Durchsatz um bis zu 20-40%. Es gibt keine Auswirkungen auf die gültige Anforderungsverarbeitung.

Die HTTP-Protokollierungs-Middleware wird jetzt in einem Pool der ResponseBufferingStream Instanzen zusammengefasst, wodurch die Zuweisungen pro Anforderung reduziert werden, wenn die Protokollierung des Antworttexts oder Interceptors aktiviert sind.

Bahnbrechende Änderungen

Verwenden Sie die Artikel in "Breaking changes in .NET ", um nach wichtigen Änderungen zu suchen, die beim Aktualisieren einer App auf eine neuere Version von .NET gelten können.

  • Last updated on