Neuerungen in ASP.NET Core 2.2

In diesem Artikel werden die wichtigsten Änderungen in ASP.NET Core 2.2 hervorgehoben und Links zu relevanter Dokumentation bereitgestellt.

Open API Analyzers & Conventions (ASP.NET Core 2.2.0 Preview 1: OpenAPI-Analysetools und -Konventionen)

OpenAPI (früher Swagger) ist eine sprachunabhängige Spezifikation für das Beschreiben von REST-APIs. Das OpenAPI-Ökosystem verfügt über Tools, mit dem sich Clientcode mithilfe der Spezifikation ermitteln, testen und erzeugen lässt. Unterstützung für das Generieren und Visualisieren von OpenAPI-Dokumenten in ASP.NET Core MVC wird über in der Community entstandene Projekte wie NSwag und Swashbuckle.AspNetCore bereitgestellt. ASP.NET Core 2.2 bietet verbesserte Tools und Runtimefunktionen für die Erstellung von OpenAPI-Dokumenten.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Unterstützung bei Problemdetails

In ASP.NET Core 2.1 wurde ProblemDetails eingeführt, basierend auf der RFC 7807-Spezifikation für die Übertragung von Fehlerdetails mit einer HTTP-Antwort. In 2.2 ist ProblemDetails die Standardantwort für Clientfehlercodes in Controllern mit dem ApiControllerAttribute. Ein IActionResult, das einen Statuscode für Clientfehler (4xx) zurückgegeben hat, gibt jetzt einen ProblemDetails-Text zurück. Das Ergebnis enthält auch eine Korrelations-ID, die zum Korrelieren des Fehlers mithilfe von Anforderungsprotokollen verwendet werden kann. Bei Clientfehlern verwendet ProducesResponseType standardmäßig ProblemDetails als Antworttyp. Dies wird in der OpenAPI- bzw. Swagger-Ausgabe dokumentiert, die mit NSwag oder Swashbuckle.AspNetCore generiert wird.

Endpunktrouting

ASP.NET Core 2.2 verwendet ein neues System für das Endpunktrouting zum verbesserten Verteilen von Anforderungen. Die Änderungen umfassen neue API-Elemente für das Generieren von Links sowie Transformatoren für Routenparameter.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Integritätsprüfungen

Ein neuer Dienst für Integritätsprüfungen vereinfacht die Verwendung von ASP.NET Core in Umgebungen, in denen Integritätsprüfungen erforderlich sind, wie z.B. Kubernetes. Integritätsprüfungen umfassen Middleware und einen Satz Bibliotheken, die eine Abstraktion und einen Dienst für IHealthCheck definieren.

Integritätsprüfungen werden von einem Containerorchestrator oder Lastenausgleichsmodul verwendet, um schnell zu ermitteln, ob ein System normal auf Anforderung reagiert. Ein Containerorchestrator kann auf eine fehlerhafte Integritätsprüfung reagieren, indem die Ausführung einer Bereitstellung angehalten oder ein Container neu gestartet wird. Ein Lastenausgleichsmodul kann auf eine Integritätsprüfung reagieren, indem Datenverkehr von der fehlerhaften Instanz des Diensts weggeleitet wird.

Integritätsprüfungen werden von einer Anwendung als HTTP-Endpunkt verfügbar gemacht, der von Überwachungssystemen verwendet wird. Integritätsprüfungen können für eine Vielzahl von Echtzeit-Überwachungsszenarien und -Überwachungssystemen konfiguriert werden. Der Integritätsprüfungsdienst lässt sich in das BeatPulse-Projekt integrieren. Damit lassen sich Überprüfungen für Dutzende von beliebten Systemen und Abhängigkeiten einfacher hinzufügen.

Weitere Informationen finden Sie unter Integritätsprüfungen in ASP.NET Core.

HTTP/2 in Kestrel

In ASP.NET Core 2.2 wurde Unterstützung für HTTP/2 hinzugefügt.

HTTP/2 ist eine umfassende Überarbeitung des HTTP-Protokolls. HTTP/2 bietet u. a. die folgenden wichtigen Features:

  • Unterstützung für Headerkomprimierung.
  • Streams mit vollständigem Multiplexing über eine einzelne Verbindung.

HTTP/2 behält zwar die HTTP-Semantik bei (z. B. HTTP-Header und Methoden), ist aber im Vergleich zu HTTP/1.x ein Breaking Change in Bezug darauf, wie Daten in Frames aufgeteilt und zwischen Client und Server gesendet werden.

Aufgrund dieser Änderung bei der Frameerstellung müssen Server und Clients die verwendete Protokollversion aushandeln. Application-Layer Protocol Negotiation (ALPN) ist eine TLS-Erweiterung, die es dem Server und dem Client ermöglicht, die verwendete Protokollversion im Rahmen des TLS-Handshakes auszuhandeln. Es ist zwar möglich, dass Server und Client das Protokoll vorher kennen, aber alle wichtigen Browser unterstützt ALPN als einzige Möglichkeit, eine HTTP/2-Verbindung herzustellen.

Weitere Informationen finden Sie unter HTTP/2-Unterstützung.

Kestrel-Konfiguration

In früheren Versionen von ASP.NET Core werden Kestrel-Optionen durch Aufrufen von UseKestrel konfiguriert. In 2.2 werden Kestrel-Optionen durch Aufrufen von ConfigureKestrel auf dem Host-Generator konfiguriert. Diese Änderung löst ein Problem mit der Reihenfolge von IServer-Registrierungen für das In-Process-Hosting. Weitere Informationen finden Sie in den folgenden Ressourcen:

IIS-In-Process-Hosting

In früheren Versionen von ASP.NET Core dient IIS als Reverseproxy. In 2.2 kann das ASP.NET Core-Modul die CoreCLR starten und eine App im IIS-Workerprozess (w3wp.exe) hosten. Das In-Process-Hosting verbessert die Leistung und Diagnose beim Ausführen mit IIS.

Weitere Informationen finden Sie unter In-Process-Hosting für IIS.

SignalR-Java-Client

ASP.NET Core 2.2 führt einen Java-Client für SignalR ein. Dieser Client unterstützt die Verbindung mit einem ASP.NET Core-SignalR-Server über Java-Code, einschließlich Android-Apps.

Weitere Informationen finden Sie unter ASP.NET Core SignalR-Java-Client.

Verbesserungen an CORS

In früheren Versionen von ASP.NET Core ermöglicht CORS-Middleware das Senden von Accept-, Accept-Language-, Content-Language- und Origin-Headern unabhängig von den in CorsPolicy.Headers konfigurierten Werten. In 2.2 ist ein Abgleich mit einer CORS-Middleware-Richtlinie nur möglich, wenn die in Access-Control-Request-Headers gesendeten Header exakt mit den in WithHeaders angegebenen Headern übereinstimmen.

Weitere Informationen finden Sie unter CORS-Middleware.

Antwortkomprimierung

ASP.NET Core 2.2 kann Antworten mit dem Brotli-Komprimierungsformat komprimieren.

Weitere Informationen finden Sie unter Middleware für die Antwortkomprimierung unterstützt die Brotli-Komprimierung.

Projektvorlagen

ASP.NET Core-Webprojektvorlagen wurden auf Bootstrap 4 und Angular 6 aktualisiert. Der neue Look ist optisch vereinfacht, sodass Sie die wichtigen Strukturen einer App leichter erkennen können.

Home or Index page

Leistung bei der Überprüfung

Das Überprüfungssystem von MVC ist erweiterbar und flexibel und ermöglicht es Ihnen, für jede Anforderung zu festzulegen, welche Validierungssteuerelemente für ein bestimmtes Modell gelten. Dies ist sehr nützlich für die Erstellung von komplexen Validierungsanbietern. In den meisten Fällen verwendet eine Anwendung jedoch nur die integrierten Validierungssteuerelemente und benötigt diese zusätzliche Flexibilität nicht. Integrierte Validierungssteuerelemente umfassen Datenanmerkungen wie [Required], [StringLength] und IValidatableObject.

In ASP.NET Core 2.2 kann MVC die Überprüfung kurzschließen, wenn festgestellt wird, dass ein bestimmter Modellgraph keine Überprüfung erfordert. Das Überspringen von Überprüfungsergebnissen bietet erhebliche Verbesserungen beim Überprüfen von Modellen, die keine Validierungssteuerelemente besitzen oder besitzen können. Hierzu gehören Objekte wie Sammlungen von primitiven (z.B. byte[], string[] und Dictionary<string, string>) oder komplexen Objektgraphen mit einer geringen Anzahl von Validierungssteuerelementen.

Leistung von HTTP-Clients

In ASP.NET Core 2.2 wurde die Leistung von SocketsHttpHandler verbessert, indem Sperrkonflikte für den Verbindungspool reduziert wurden. Bei Apps, die viele ausgehende HTTP-Anforderungen senden – beispielsweise Microservicearchitekturen – wird der Durchsatz verbessert. Unter Last kann der HttpClient-Durchsatz um bis zu 60 % unter Linux und bis zu 20 % unter Windows gesteigert werden.

Weitere Informationen finden Sie beim Pull Request, durch den diese Verbesserung erzielt wurde.

Zusätzliche Informationen

Die vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu ASP.NET Core 2.2.