Neuerungen in ASP.NET Core 5.0
In diesem Artikel werden die wichtigsten Änderungen in ASP.NET Core 5.0 aufgezeigt und Links zur relevanten Dokumentation bereitgestellt.
ASP.NET Core MVC- und Razor-Verbesserungen
Modellbindung von DateTime als UTC
Die Modellbindung unterstützt jetzt die Bindung von UTC-Zeitzeichenfolgen an DateTime. Wenn die Anforderung eine UTC-Zeitzeichenfolge enthält, bindet die Modellbindung Sie an ein UTC-DateTime-Element. Beispielsweise wird die folgende Zeitzeichenfolge an das UTC-DateTime-Element gebunden: https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z
Modellbindung und Validierung mit Datensatztypen in C# 9.0
Datensatztypen in C# 9.0 können mit der Modellbindung in einem Model View Controller (MVC) oder einer Razor-Seite verwendet werden. Datensatztypen lassen sich gut zur Modellierung von Daten verwenden, die über das Netzwerk übertragen werden.
Beispielsweise wird im folgenden PersonController-Element der Person-Datensatztyp mit Modellbindung und Formularvalidierung verwendet:
public record Person([Required] string Name, [Range(0, 150)] int Age);
public class PersonController
{
public IActionResult Index() => View();
[HttpPost]
public IActionResult Index(Person person)
{
// ...
}
}
Die Datei Person/Index.cshtml enthält Folgendes:
@model Person
<label>Name: <input asp-for="Model.Name" /></label>
<span asp-validation-for="Model.Name" />
<label>Age: <input asp-for="Model.Age" /></label>
<span asp-validation-for="Model.Age" />
Verbesserungen an DynamicRouteValueTransformer
Mit ASP.NET Core 3.1 wurde DynamicRouteValueTransformer als Methode zur Verwendung eines benutzerdefinierten Endpunkts für die dynamische Auswahl einer MVC-Aktion oder einer Razor-Seite eingeführt. ASP.NET Core 5.0-Anwendungen können den Status an ein DynamicRouteValueTransformer-Element übergeben und die ausgewählten Endpunkte filtern.
Sonstiges
- Das [Compare]-Attribut kann auf Eigenschaften eines Razor-Seitenmodells angewendet werden.
- Parameter und Eigenschaften, die vom Text gebunden werden, gelten standardmäßig als erforderlich.
Web-API
OpenAPI-Spezifikation standardmäßig aktiviert
Die OpenAPI-Spezifikation ist ein Branchenstandard zum Beschreiben von HTTP-APIs und deren Integration in komplexe Geschäftsprozesse oder Drittanbieter. OpenAPI wird von allen Cloudanbietern und zahlreichen API-Registrierungen weitgehend unterstützt. Apps, die OpenAPI-Dokumente aus Web-APIs ausgeben, haben eine Vielzahl neuer Möglichkeiten, mit denen diese APIs verwendet werden können. In Zusammenarbeit mit den Betreuern des Open Source-Projekts Swashbuckle.AspNetCore enthält die ASP.NET Core-API-Vorlage eine NuGet-Abhängigkeit von Swashbuckle. Swashbuckle ist ein gängiges Open-Source-NuGet-Paket, das OpenAPI-Dokumente dynamisch ausgibt. Swashbuckle führt dies durch das Introspektieren über die API-Controller und das Erstellen des OpenAPI-Dokuments zur Laufzeit oder zur Buildzeit mithilfe der Swashbuckle-CLI aus.
In ASP.NET Core 5.0 wird die OpenAPI-Unterstützung von den Web-API-Vorlagen standardmäßig aktiviert. So deaktivieren Sie OpenAPI:
Über die Befehlszeile:
dotnet new webapi --no-openapi trueÜber Visual Studio: Deaktivieren Sie die Option Support für OpenAPI aktivieren.
Alle .csproj-Dateien, die für Web-API-Projekte erstellt werden, enthalten den Verweis auf das Swashbuckle.AspNetCore-NuGet-Paket.
<ItemGroup>
<PackageReference Include="Swashbuckle.AspNetCore" Version="5.5.1" />
</ItemGroup>
Der von der Vorlage generierte Code enthält Code in Startup.ConfigureServices, der die Erstellung des OpenAPI-Dokuments aktiviert:
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo { Title = "WebApp1", Version = "v1" });
});
}
Die Startup.Configure-Methode fügt die Swashbuckle-Middleware hinzu, die Folgendes ermöglicht:
- Dokumenterstellungsprozess
- Die Seite für die Swagger-Benutzeroberfläche ist standardmäßig im Entwicklungsmodus.
Der von der Vorlage generierte Code wird nicht versehentlich die Beschreibung der API bei der Veröffentlichung in der Produktion verfügbar machen.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseSwagger(); // UseSwaggerUI Protected by if (env.IsDevelopment())
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
"WebApp1 v1"));
}
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
Azure API Management-Import
Wenn ASP.NET Core API-Projekte OpenAPI aktivieren, bietet die Veröffentlichung mit Visual Studio 2019 Version 16.8 und höher automatisch einen zusätzlichen Schritt bei der Veröffentlichung. Entwickler, die Azure API Management verwenden, haben die Möglichkeit, die APIs während des Veröffentlichungsflusses automatisch in Azure API Management zu importieren:
Bessere Startbedingungen für Web-API-Projekte
Wenn OpenAPI standardmäßig aktiviert ist, werden die Startbedingungen für die App (F5) für Web-API-Entwickler erheblich verbessert. In ASP.NET Core 5.0 ist die Web-API-Vorlage zum Laden der Seite für die Swagger-Benutzeroberfläche vorkonfiguriert. Auf der Seite für die Swagger-Benutzeroberfläche finden Sie die Dokumentation, die für die veröffentlichte API hinzugefügt wurde. Zudem können Sie von dort aus auch APIs mit einem einzigen Mausklick testen.
Blazor
Leistungsverbesserungen
Für .NET 5 haben wir die Leistung der .NET WebAssembly-Laufzeitumgebung erheblich verbessert, wobei der Schwerpunkt auf dem komplexen UI-Rendering und der JSON-Serialisierung lag. In unseren Leistungstests ist Blazor WebAssembly in .NET 5 in den meisten Szenarios zwei- bis dreimal schneller. Weitere Informationen finden Sie im ASP.NET-Blog: ASP.NET Core updates in .NET 5 Release Candidate 1 (ASP.NET Core-Updates in .NET 5 Release Candidate).
CSS-Isolation
Blazor unterstützt jetzt das Definieren von CSS-Formaten, die auf eine bestimmte Komponente zugeschnitten sind. Komponentenspezifische CSS-Formate erleichtern die Auseinandersetzung mit den Formaten in einer Anwendung und die Vermeidung unbeabsichtigter Begleiterscheinungen von globalen Formaten. Weitere Informationen finden Sie unter Blazor CSS-Isolation in ASP.NET Core.
Neue InputFile-Komponente
Die InputFile-Komponente ermöglicht das Lesen einer oder mehrerer Dateien, die von einem Benutzer für den Upload ausgewählt wurden. Weitere Informationen finden Sie unter Blazor-Dateiuploads in ASP.NET Core.
Neue InputRadio- und InputRadioGroup-Komponenten
Blazor verfügt über integrierte InputRadio- und InputRadioGroup-Komponenten, die die Datenbindung an Optionsfeldgruppen mit integrierter Validierung vereinfachen. Weitere Informationen finden Sie unter ASP.NET Core Blazor Eingabekomponenten.
Komponentenvirtualisierung
Verbessern Sie die wahrgenommene Leistung von Komponentenrendering mithilfe der integrierten Virtualisierungsunterstützung des Blazor-Frameworks. Weitere Informationen finden Sie unter Razor-Komponentenvirtualisierung in ASP.NET Core.
Unterstützung von ontoggle-Ereignissen
Blazor-Ereignisse unterstützen jetzt das ontoggle-DOM-Ereignis. Weitere Informationen finden Sie unter Ereignisbehandlung in Blazor in ASP.NET Core.
Festlegen des Fokus auf die Benutzeroberfläche in Blazor-Apps
Verwenden Sie die FocusAsync-Hilfsmethode für Elementverweise, um den Benutzeroberflächenfokus auf dieses Element festzulegen. Weitere Informationen finden Sie unter Ereignisbehandlung in Blazor in ASP.NET Core.
Benutzerdefinierte CSS-Klassenattribute für die Validierung
CSS-Klassenattribute für die benutzerdefinierte Validierung sind nützlich, wenn eine Integration in CSS-Frameworks wie Bootstrap erfolgt. Weitere Informationen finden Sie unter ASP.NET Core Blazor Formularvalidierung.
IAsyncDisposable-Unterstützung
Razor-Komponenten unterstützen jetzt die IAsyncDisposable-Schnittstelle für das asynchrone Release zugeordneter Ressourcen.
-JavaScript-Isolation und Objektverweise
Blazor aktiviert JavaScript-Isolierung in JavaScript-Standardmodulen. Weitere Informationen finden Sie unter Aufrufen von JavaScript-Funktionen über .NET-Methoden in Blazor in ASP.NET Core.
Formularkomponenten unterstützen Anzeigenamen
Die folgenden integrierten Komponenten unterstützen Anzeigenamen mit dem DisplayName-Parameter:
InputDateInputNumberInputSelect
Weitere Informationen finden Sie unter Übersicht über ASP.NET Core Blazor Formulare.
Catch-All-Routenparameter
Catch-All-Routenparameter, die Pfade über mehrere Ordnergrenzen hinweg erfassen, werden in Komponenten unterstützt. Weitere Informationen finden Sie unter ASP.NET Core: Routing und Navigation in Blazor.
Verbesserungen beim Debugging
Das Debuggen von Blazor WebAssembly-Apps wurde in ASP.NET Core 5.0 verbessert. Außerdem wird das Debuggen jetzt für Visual Studio für Mac unterstützt. Weitere Informationen finden Sie unter Debuggen von ASP.NET Core Blazor-Apps.
Microsoft Identity v2.0 und MSAL v2.0
Blazor-Sicherheit verwendet jetzt Microsoft Identity v2.0 (Microsoft.Identity.Web und Microsoft.Identity.Web.UI) und MSAL v2.0. Weitere Informationen finden Sie in den Themen unter Blazor Sicherheit und Identity Knoten.
Geschützter Browserspeicher für Blazor Server
Für Blazor Server-Apps gibt es jetzt eine integrierte Unterstützung zum Speichern des App-Status im Browser, der mit ASP.NET Core-Datenschutzfunktionen vor unbefugtem Zugriff geschützt wird. Daten können entweder im lokalen Browserspeicher oder im Sitzungsspeicher gespeichert werden. Weitere Informationen finden Sie unter Blazor-Zustandsverwaltung in ASP.NET Core.
Blazor WebAssembly-Prerendering
Die Komponentenintegration wurde für verschiedene Hostingmodelle verbessert, und Blazor WebAssembly-Apps können jetzt die Ausgabe auf dem Server vorab rendern.
Verbesserungen beim Kürzen/Verknüpfen
Blazor WebAssembly führt die IL-Kürzung/Verknüpfung (Intermediate Language) während eines Builds durch, um nicht benötigte Zwischensprache aus den Ausgabeassemblys der Anwendung zu kürzen. Ab dem Release von ASP.NET Core 5.0 führt Blazor WebAssembly eine verbesserte Kürzung mit zusätzlichen Konfigurationsoptionen durch. Weitere Informationen finden Sie unter Konfigurieren des Trimmers für Blazor in ASP.NET Core und Kürzungsoptionen.
Browserkompatibilitäts-Analysetool
Blazor WebAssembly-Apps zielen auf die vollständige .NET-API-Oberfläche ab, aber aufgrund von Browsersandboxeinschränkungen werden nicht alle .NET-APIs in WebAssembly unterstützt. Nicht unterstützte APIs lösen PlatformNotSupportedException bei der Ausführung in Webassembly aus. Ein Plattformkompatibilitäts-Analysetool warnt den Entwickler, wenn die API APIs verwendet, die nicht von den Zielplattformen der App unterstützt werden. Weitere Informationen finden Sie unter Nutzen von ASP.NET Core Razor-Komponenten über eine Razor-Klassenbibliothek (RCL).
Lazy Loading-Assemblys
Die Startleistung einer Blazor WebAssembly-App kann verbessert werden, indem das Laden einiger Anwendungsassemblys verzögert wird, bis sie erforderlich sind. Weitere Informationen finden Sie unter Verzögertes Laden von Assemblys in Blazor WebAssembly in ASP.NET Core.
Aktualisierte Globalisierungsunterstützung
Die Globalisierungsunterstützung ist für Blazor WebAssembly basierend auf den internationalen Komponenten für Unicode (ICU) verfügbar. Weitere Informationen finden Sie unter Blazor in ASP.NET Core: Globalisierung und Lokalisierung.
gRPC
In gRPC wurden viele Leistungsverbesserungen vorgenommen. Weitere Informationen finden Sie unter gRPC performance improvements in .NET 5 (gPRC-Leistungsverbesserungen in .NET 5).
Weitere gRPC-Informationen finden Sie unter Übersicht zu gRPC in .NET.
SignalR
SignalR-Hubfilter
SignalR Hubfilter, die in ASP.NET als Hubpipelines bezeichnet werdenSignalR, sind ein Feature, das die Ausführung von Code vor und nach dem Aufruf von Hubmethoden ermöglicht. Das Ausführen von Code vor und nach dem Aufruf von Hubmethoden ist vergleichbar damit, wie mithilfe von Middleware Code vor und nach einer HTTP-Anforderung ausgeführt werden kann. Zu den allgemeinen Verwendungsmöglichkeiten zählen die Protokollierung, die Fehlerbehandlung und die Argumentvalidierung.
Weitere Informationen finden Sie unter Use hub filters in ASP.NET CoreSignalR (Verwenden von Hubfiltern in ASP.NET Core).
Parallele SignalR-Hubaufrufe
ASP.NET Core SignalR ist nun in der Lage, parallele Hubaufrufe zu verarbeiten. Das Standardverhalten kann so geändert werden, dass Clients gleichzeitig mehr als eine Hubmethode aufrufen:
public void ConfigureServices(IServiceCollection services)
{
services.AddSignalR(options =>
{
options.MaximumParallelInvocationsPerClient = 5;
});
}
Hinzugefügte MessagePack-Unterstützung im SignalR-Java-Client
Ein neues Paket, com.microsoft.signalr.messagepack, fügt dem SignalR-Java-Client MessagePack-Unterstützung hinzu. Um das MessagePack-Hubprotokoll zu verwenden, fügen Sie .withHubProtocol(new MessagePackHubProtocol()) zum Verbindungs-Generator hinzu:
HubConnection hubConnection = HubConnectionBuilder.create(
"http://localhost:53353/MyHub")
.withHubProtocol(new MessagePackHubProtocol())
.build();
Kestrel
Wiederaufladbare Endpunkte über Konfiguration: Kestrel können Änderungen an der Konfiguration erkennen, die an KestrelServerOptions.Configure übergeben werden, und sich von vorhandenen Endpunkten lösen und sich an neue Endpunkte binden, ohne dass ein Neustart der Anwendung erforderlich ist, wenn der
reloadOnChange-Parametertrueist. Standardmäßig wird bei Verwendung von ConfigureWebHostDefaults oder CreateDefaultBuilderKestrel mit aktiviertemreloadOnChange-Element an den Konfigurationsunterabschnitt "Kestrel" gebunden. Apps müssenreloadOnChange: trueübergeben, wennKestrelServerOptions.Configuremanuell aufgerufen wird, um erneut ladbare Endpunkte abzurufen.Verbesserungen bei HTTP/2-Antwortheadern. Weitere Informationen finden Sie im nächsten Abschnitt Leistungsverbesserungen.
Unterstützung für zusätzliche Endpunkttypen im Socketstransport: Als Ergänzung der neuen API, die in System.Net.Sockets eingeführt wurde, ermöglicht der Socketsstandardtransport in Kestrel die Bindung sowohl an vorhandene Dateihandles als auch an Unix-Domänensockets. Die Unterstützung für die Bindung an vorhandene Dateihandles ermöglicht die Verwendung der vorhandenen
Systemd-Integration, ohne dass derlibuv-Transport erforderlich ist.Decodierung von benutzerdefiniertem Header in Kestrel: Mithilfe von Apps kann festgelegt werden, welche Codierung (Encoding) verwendet werden soll, um eingehende Header anhand des Headernamens zu interpretieren, anstatt standardmäßig UTF-8 zu verwenden. Legen Sie die Eigenschaft
Microsoft.AspNetCore.Server.Kestrel.KestrelServerOptions.RequestHeaderEncodingSelectorfest, um die zu verwendende Codierung anzugeben:public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.ConfigureKestrel(options => { options.RequestHeaderEncodingSelector = encoding => { return encoding switch { "Host" => System.Text.Encoding.Latin1, _ => System.Text.Encoding.UTF8, }; }; }); webBuilder.UseStartup<Startup>(); });
Für den Kestrel-Endpunkt spezifische Optionen über die Konfiguration
Ab sofort wird das Konfigurieren der endpunktspezifischen Optionen für Kestrel über die Konfiguration unterstützt. Die endpunktspezifischen Konfigurationen umfassen Folgendes:
- Verwendete HTTP-Protokolle
- Verwendete TLS-Protokolle
- Ausgewähltes Zertifikat
- Clientzertifikatmodus
Die Konfiguration ermöglicht die Angabe, welches Zertifikat auf Grundlage des angegebenen Servernamens ausgewählt wird. Der Servername ist Teil der SNI-Erweiterung (Servernamensanzeige) des TLS-Protokolls, wie vom Client angegeben. Die Konfiguration von Kestrel unterstützt auch ein Platzhalterpräfix im Hostnamen.
Im folgenden Beispiel wird gezeigt, wie eine endpunktspezifische Option mithilfe einer Konfigurationsdatei angegeben wird:
{
"Kestrel": {
"Endpoints": {
"EndpointName": {
"Url": "https://*",
"Sni": {
"a.example.org": {
"Protocols": "Http1AndHttp2",
"SslProtocols": [ "Tls11", "Tls12"],
"Certificate": {
"Path": "testCert.pfx",
"Password": "testPassword"
},
"ClientCertificateMode" : "NoCertificate"
},
"*.example.org": {
"Certificate": {
"Path": "testCert2.pfx",
"Password": "testPassword"
}
},
"*": {
// At least one sub-property needs to exist per
// SNI section or it cannot be discovered via
// IConfiguration
"Protocols": "Http1",
}
}
}
}
}
}
Servernamensanzeige (SNI) ist eine TLS-Erweiterung zum Einbinden einer virtuellen Domäne als Teil der SSL-Aushandlung. Dies bedeutet, dass der Name der virtuellen Domäne oder eines Hosts zur Identifizierung des Netzwerkendpunkts verwendet werden kann.
Leistungsverbesserungen
HTTP/2
Erhebliche Reduzierung der Zuweisungen im HTTP/2-Codepfad.
Unterstützung für dynamische HPack-Komprimierung von HTTP/2-Antwortheadern in Kestrel. Weitere Informationen finden Sie unter Größe der Headertabelle und HPACK: The Silent Killer (Feature) of HTTP/2 (HPACK: Der lautlose Killer (Feature) von HTTP/2).
Senden von HTTP/2-PING-Frames: HTTP/2 verfügt über einen Mechanismus zum Senden von PING-Frames, um sicherzustellen, dass eine Verbindung im Leerlauf noch funktionsfähig ist. Das Sicherstellen einer funktionsfähigen Verbindung ist besonders nützlich, wenn mit lange dauernden Streams gearbeitet wird, die oft im Leerlauf sind und nur sporadisch Aktivität aufweisen, z. B. gRPC-Streams. In Kestrel können Apps periodische PING-Frames senden, indem sie Grenzwerte für KestrelServerOptions festlegen:
public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.ConfigureKestrel(options => { options.Limits.Http2.KeepAlivePingInterval = TimeSpan.FromSeconds(10); options.Limits.Http2.KeepAlivePingTimeout = TimeSpan.FromSeconds(1); }); webBuilder.UseStartup<Startup>(); });
Container
Vor .NET 5.0 war es zum Erstellen und Veröffentlichen einer Dockerfile für eine ASP.NET Core-Anwendung erforderlich, das gesamte .NET Core SDK und das ASP.NET Core-Image zu pullen. Mit dieser Version wird das Pullen der SDK-Imagebytes reduziert, und die für das ASP.NET Core-Image gepullten Bytes werden größtenteils entfernt. Weitere Informationen finden Sie in diesem GitHub-Issue-Kommentar.
Authentifizierung und Autorisierung
Microsoft Entra-ID-Authentifizierung bei Microsoft.Identity.Web
Die ASP.NET Core-Projektvorlagen lassen sich jetzt in Microsoft.Identity.Web integrieren, um die Authentifizierung mit Microsoft Entra-ID abzuwickeln. Das Microsoft.Identity.Web-Paket bietet Folgendes:
- Eine bessere Authentifizierung über Microsoft Entra-ID.
- Eine einfachere Möglichkeit, auf Azure-Ressourcen im Namen Ihrer Benutzer zuzugreifen, einschließlich Microsoft Graph. Weitere Informationen finden Sie im Microsoft.Identity.Web-Beispiel, das mit einer einfachen Anmeldung beginnt und sich über Mehrinstanzenfähigkeit, die Verwendung von Azure-APIs, die Verwendung von Microsoft Graph und den Schutz Ihrer eigenen APIs erstreckt.
Microsoft.Identity.Webist neben .NET 5 verfügbar.
Zulassen des anonymen Zugriffs auf einen Endpunkt
Die AllowAnonymous-Erweiterungsmethode ermöglicht den anonymen Zugriff auf einen Endpunkt:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapGet("/", async context =>
{
await context.Response.WriteAsync("Hello World!");
})
.AllowAnonymous();
});
}
Benutzerdefinierte Behandlung von Autorisierungsfehlern
Die benutzerdefinierte Behandlung von Autorisierungsfehlern ist mit der neuen IAuthorizationMiddlewareResultHandler-Schnittstelle, die von der Middleware zur Autorisierung aufgerufen wird, jetzt einfacher. Die Standardimplementierung bleibt die gleiche, aber ein benutzerdefinierter Handler kann in Dependency Injection registriert werden. So werden benutzerdefinierte HTTP-Antworten zugelassen, die sich danach richten, warum die Autorisierung fehlgeschlagen ist. Weitere Informationen finden Sie in diesem Beispiel, das die Verwendung von IAuthorizationMiddlewareResultHandler veranschaulicht.
Autorisierung bei Verwendung des Endpunktroutings
Die Autorisierung bei Verwendung des Endpunktroutings empfängt jetzt das HttpContext-Element statt der Endpunktinstanz. Dadurch kann die Autorisierungsmiddleware auf die RouteData-Eigenschaft und andere Eigenschaften von HttpContext zugreifen, auf die über die Endpoint-Klasse nicht zugegriffen werden konnte. Der Endpunkt kann mit context.GetEndpoint aus dem Kontext abgerufen werden.
Rollenbasierte Zugriffssteuerung mit Kerberos-Authentifizierung und LDAP unter Linux
Weitere Informationen finden Sie unter Kerberos authentication and role-based access control (RBAC) (Kerberos-Authentifizierung und rollenbasierte Zugriffssteuerung (RBAC)).
API-Verbesserungen
JSON-Erweiterungsmethoden für HttpRequest und HttpResponse
JSON-Daten können mit den neuen Erweiterungsmethoden ReadFromJsonAsync und WriteAsJsonAsync aus einem HttpRequest- und HttpResponse-Element gelesen und geschrieben werden. Diese Erweiterungsmethoden verarbeiten die JSON-Daten mithilfe des Serialisierungsmoduls System.Text.Json. Mit der neuen HasJsonContentType-Erweiterungsmethode lässt sich auch überprüfen, ob eine Anforderung einen JSON-Inhaltstyp aufweist.
Die JSON-Erweiterungsmethoden können mit Endpunktrouting kombiniert werden, um JSON-APIs in einem Programmierstil zu erstellen, der als Route-zu-Code bezeichnet wird. Diese neue Option bietet Entwicklern die Möglichkeit, grundlegende JSON-APIs auf einfache Art und Weise zu erstellen. Beispielsweise kann eine Web-App, die nur über wenige Endpunkte verfügt, anstatt der vollständigen Funktionalität von ASP.NET Core-MVC auch Route-zu-Code nutzen:
endpoints.MapGet("/weather/{city:alpha}", async context =>
{
var city = (string)context.Request.RouteValues["city"];
var weather = GetFromDatabase(city);
await context.Response.WriteAsJsonAsync(weather);
});
System.Diagnostics.Activity
Als Standardformat für System.Diagnostics.Activity wird jetzt standardmäßig das W3C-Format verwendet. Dadurch wird die Unterstützung für verteilte Ablaufverfolgung in ASP.NET Core standardmäßig mit mehr Frameworks interoperabel.
FromBodyAttribute
FromBodyAttribute unterstützt nun die Konfiguration einer Option, mit der diese Parameter oder Eigenschaften als optional betrachtet werden können:
public IActionResult Post([FromBody(EmptyBodyBehavior = EmptyBodyBehavior.Allow)]
MyModel model)
{
...
}
Sonstige Verbesserungen
Ab sofort werden auf ASP.NET-Core-Assemblys Nullable-Anmerkungen angewendet. Außerdem ist vorgesehen, den größten Teil der allgemeinen öffentlichen API-Oberfläche des .NET 5-Frameworks mit Anmerkungen zu versehen.
Steuerung der Startklassenaktivierung
Es wurde eine zusätzliche UseStartup-Überladung hinzugefügt, mit der eine App eine Factorymethode zum Steuern der Startup-Klassenaktivierung bereitstellen kann. Das Steuern der Startup-Klassenaktivierung ist nützlich, um zusätzliche Parameter an Startup zu übergeben, die zusammen mit dem Host initialisiert werden:
public class Program
{
public static async Task Main(string[] args)
{
var logger = CreateLogger();
var host = Host.CreateDefaultBuilder()
.ConfigureWebHost(builder =>
{
builder.UseStartup(context => new Startup(logger));
})
.Build();
await host.RunAsync();
}
}
Automatische Aktualisierung mit „dotnet watch“
In .NET 5 wird beim Ausführen von dotnet watch in einem ASP.NET Core-Projekt der Standardbrowser gestartet und automatisch aktualisiert, wenn Änderungen am Code vorgenommen werden. Dies bedeutet, Sie haben folgende Möglichkeiten:
- Öffnen Sie ein ASP.NET Core-Projekt in einem Text-Editor.
- Führen Sie
dotnet watchaus. - Konzentrieren Sie sich auf die Codeänderungen, während das Tool das Neuerstellen, Neustarten und erneute Laden der App übernimmt.
Formatierer für die Konsolenprotokollierung
Es wurden Verbesserungen an der Konsolenprotokollierung in der Microsoft.Extensions.Logging-Bibliothek vorgenommen. Entwickler können nun ein benutzerdefiniertes ConsoleFormatter-Programm implementieren, um Formatierungen und Farbgebungen der Konsolenausgabe vollständig zu steuern. Die Formatierungs-APIs ermöglichen eine umfangreiche Formatierung, indem eine Teilmenge der VT-100-Escapesequenzen implementiert wird. VT-100 wird von den meisten modernen Terminals unterstützt. Die Konsolenprotokollierung kann Escapesequenzen auf nicht unterstützten Terminals analysieren, sodass Entwickler einen einzelnen Formatierer für alle Terminals erstellen können.
JSON-Konsolenprotokollierung
Zusätzlich zur Unterstützung von benutzerdefinierten Formatierern gibt es nun auch einen integrierten JSON-Formatierer, der strukturierte JSON-Protokolle an die Konsole ausgibt. Der folgende Code zeigt, wie Sie von der Standardprotokollierung zu JSON wechseln:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.AddJsonConsole(options =>
{
options.JsonWriterOptions = new JsonWriterOptions()
{ Indented = true };
});
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
An die Konsole ausgegebene Protokollmeldungen sind JSON-formatiert:
{
"EventId": 0,
"LogLevel": "Information",
"Category": "Microsoft.Hosting.Lifetime",
"Message": "Now listening on: https://localhost:5001",
"State": {
"Message": "Now listening on: https://localhost:5001",
"address": "https://localhost:5001",
"{OriginalFormat}": "Now listening on: {address}"
}
}
ASP.NET Core