Udostępnij za pośrednictwem

Co nowego w programie ASP.NET Core 6.0

  • Artykuł

W tym artykule przedstawiono najważniejsze zmiany w programie ASP.NET Core 6.0 z linkami do odpowiedniej dokumentacji.

ASP.NET Core MVC i Razor ulepszenia

Minimalne interfejsy API

Minimalne interfejsy API są tworzone w celu tworzenia interfejsów API HTTP z minimalnymi zależnościami. Są one idealne dla mikrousług i aplikacji, które chcą uwzględniać tylko minimalne pliki, funkcje i zależności w ASP.NET Core. Aby uzyskać więcej informacji, zobacz:

SignalR

Tag aktywności długotrwałej dla SignalR połączeń

SignalR używa nowego Microsoft.AspNetCore.Http.Features.IHttpActivityFeature.Activity tagu, aby dodać http.long_running tag do działania żądania. IHttpActivityFeature.Activity jest używany przez usługi APM, takie jak Azure Monitor Application Insights , do filtrowania SignalR żądań od tworzenia długotrwałych alertów żądań.

SignalR ulepszenia wydajności

  • Przydziel klasę HubCallerClients raz na połączenie zamiast każdego wywołania metody centrum.
  • Unikaj alokacji zamknięcia w programie SignalRDefaultHubDispatcher.Invoke. Stan jest przekazywany do lokalnej funkcji statycznej za pośrednictwem parametrów, aby uniknąć alokacji zamknięcia. Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub.
  • Przydzielanie pojedynczego StreamItemMessage strumienia zamiast na element strumienia w strumieniu serwer-klient. Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub.

Razor kompilator

Razor Kompilator zaktualizowany w celu korzystania z generatorów źródłowych

Kompilator Razor jest teraz oparty na generatorach źródeł języka C#. Generatory źródłowe są uruchamiane podczas kompilacji i sprawdzają, co jest kompilowane w celu utworzenia dodatkowych plików skompilowanych wraz z rest projektem. Korzystanie z generatorów źródłowych upraszcza Razor kompilator i znacznie przyspiesza czas kompilacji.

Razor Kompilator nie tworzy już oddzielnego zestawu Widoki

Kompilator Razor wcześniej wykorzystał dwuetapowy proces kompilacji, który wygenerował oddzielny zestaw Widoki, który zawierał wygenerowane widoki i strony (.cshtml pliki) zdefiniowane w aplikacji. Wygenerowane typy były publiczne i w AspNetCore przestrzeni nazw.

Zaktualizowany Razor kompilator kompiluje widoki i typy stron w głównym zestawie projektu. Te typy są domyślnie generowane jako wewnętrzne zapieczętowane w AspNetCoreGeneratedDocument przestrzeni nazw. Ta zmiana poprawia wydajność kompilacji, umożliwia wdrażanie pojedynczych plików i umożliwia udział w tych typach w Przeładowywanie na gorąco.

Aby uzyskać więcej informacji na temat tej zmiany, zobacz powiązany problem z ogłoszeniem w witrynie GitHub.

ASP.NET Core wydajność i ulepszenia interfejsu API

Wprowadzono wiele zmian w celu zmniejszenia alokacji i zwiększenia wydajności w obrębie stosu:

  • Nieprzydzielająca aplikacji. Użyj metody rozszerzenia. Nowe przeciążenie app.Use programu wymaga przekazania kontekstu, do next którego zapisuje dwa wewnętrzne alokacje na żądanie, które są wymagane podczas korzystania z innego przeciążenia.
  • Zmniejszenie alokacji pamięci podczas uzyskiwania dostępu do elementu HttpRequest.Cookies. Aby uzyskać więcej informacji, zobacz ten problem w serwisie GitHub.
  • Użyj loggerMessage.Define dla systemu Windows tylko HTTP.sys serwera internetowego. Wywołania ILogger metod rozszerzeń zostały zastąpione wywołaniami metody LoggerMessage.Define.
  • Zmniejsz obciążenie na połączenie w programie SocketConnection o ok. 30%. Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub.
  • Zmniejsz alokacje, usuwając delegatów rejestrowania w typach ogólnych. Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub.
  • Szybszy dostęp GET (około 50%) do powszechnie używanych funkcji, takich jak IHttpRequestFeature, , IHttpResponseBodyFeatureIHttpResponseFeature, IRouteValuesFeaturei IEndpointFeature. Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub.
  • Użyj ciągów pojedynczego wystąpienia dla znanych nazw nagłówków, nawet jeśli nie są one w zachowanym bloku nagłówka. Użycie ciągu pojedynczego wystąpienia pomaga zapobiec wielu duplikatom tego samego ciągu w długotrwałych połączeniach, na przykład w pliku Microsoft.AspNetCore.WebSockets. Aby uzyskać więcej informacji, zobacz ten problem w serwisie GitHub.
  • Użyj ponownie elementu HttpProtocol CancellationTokenSource w pliku Kestrel. Użyj nowej metody CancellationTokenSource.TryReset , CancellationTokenSource aby ponownie użyć tokenów, jeśli nie zostały anulowane. Aby uzyskać więcej informacji, zobacz ten problem z usługą GitHub i ten film wideo.
  • Zaimplementuj i użyj elementu AdaptiveCapacityDictionary w Microsoft.AspNetCore.Http kolekcji RequestCookieCollection, aby uzyskać bardziej wydajny dostęp do słowników. Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub.

Zmniejszona ilość pamięci dla bezczynnych połączeń TLS

W przypadku długotrwałych połączeń TLS, w których dane są wysyłane tylko od czasu do czasu, znacznie zmniejszyliśmy ilość pamięci aplikacji ASP.NET Core na platformie .NET 6. Powinno to pomóc zwiększyć skalowalność scenariuszy, takich jak serwery WebSocket. Było to możliwe z powodu wielu ulepszeń w systemach System.IO.Pipelines, SslStreami Kestrel. W poniższych sekcjach opisano niektóre ulepszenia, które przyczyniły się do zmniejszenia zużycia pamięci:

Zmniejsz rozmiar System.IO.Pipelines.Pipe

Dla każdego ustanowionego połączenia dwa potoki są przydzielane w programie Kestrel:

  • Warstwa transportu do aplikacji dla żądania.
  • Warstwa aplikacji do transportu odpowiedzi.

Zmniejszając rozmiar System.IO.Pipelines.Pipe z 368 bajtów do 264 bajtów (około 28,2% redukcji), 208 bajtów na połączenie są zapisywane (104 bajty na potok).

Pool SocketSender

SocketSender obiekty (ta podklasa SocketAsyncEventArgs) mają około 350 bajtów w czasie wykonywania. Zamiast przydzielać nowy SocketSender obiekt na połączenie, można je pulować. SocketSender obiekty można pulować, ponieważ wysyłanie jest zwykle bardzo szybkie. Buforowanie zmniejsza obciążenie na połączenie. Zamiast przydzielać 350 bajtów na połączenie, przydzielane są tylko 350 bajtów na IOQueue . Alokacja odbywa się na kolejkę, aby uniknąć rywalizacji. Nasz serwer WebSocket z 5000 bezczynnymi połączeniami został przeniesiony z przydzielania ~1,75 MB (350 bajtów * 5000) do przydzielania ~2,8 kb (350 bajtów * 8) dla SocketSender obiektów.

Odczyty zerowe bajtów z protokołem SslStream

Odczyty bez buforu są techniką używaną w ASP.NET Core, aby uniknąć wynajmowania pamięci z puli pamięci, jeśli w gniazdach nie ma dostępnych danych. Przed tą zmianą nasz serwer Protokołu WebSocket z 5000 bezczynnymi połączeniami wymaganymi ok. 200 MB bez protokołu TLS w porównaniu z ok. 800 MB przy użyciu protokołu TLS. Niektóre z tych alokacji (4k na połączenie) były z Kestrel konieczności wstrzymania do ArrayPool<T> buforu podczas oczekiwania na zakończenie operacji odczytu SslStream . Biorąc pod uwagę, że te połączenia były bezczynne, żaden z odczytów nie został ukończony i zwrócił do ArrayPool, wymuszając przydzielenie ArrayPool większej ilości pamięci. Pozostałe alokacje były w SslStream sobie: bufor 4k dla uzgadniań TLS i bufor 32k dla normalnych odczytów. Na platformie .NET 6, gdy użytkownik wykonuje odczyt SslStream zerowy bajtów i nie ma dostępnych danych, SslStream wewnętrznie wykonuje odczyt zerowy bajt na bazowym strumieniu opakowanym. W najlepszym przypadku (bezczynne połączenie) te zmiany powodują oszczędności 40 KB na połączenie, jednocześnie zezwalając użytkownikowi (Kestrel) na powiadomienie, gdy dane są dostępne bez przechowywania w żadnych nieużywanych.

Odczyty bajtów zerowych za pomocą elementu PipeReader

W przypadku operacji odczytu bez buforu obsługiwanego w systemie SslStreamdodano opcję umożliwiającą wykonywanie operacji odczytu bajtów zerowych do StreamPipeReaderklasy , typu wewnętrznego, który dostosowuje element Stream do elementu PipeReader. W Kestrelsystemie element jestStreamPipeReader używany do dostosowywania bazowego SslStream do elementu PipeReader. W związku z tym konieczne było uwidocznienie tych semantyki odczytu bajtów zerowych w obiekcie PipeReader.

PipeReader Można teraz utworzyć obiekt, który obsługuje odczyty zerowe bajtów dla wszystkich bazowychStream, które obsługują semantyka odczytu bajtów zerowych (np. SslStream, NetworkStreamitp.) przy użyciu następującego interfejsu API:

var reader = PipeReader.Create(stream, new StreamPipeReaderOptions(useZeroByteReads: true));

Usuwanie płyt z obiektu SlabMemoryPool

Aby zmniejszyć fragmentację sterta, zastosowano technikę, Kestrel w której przydzielono płyty pamięci o rozmiarze 128 KB w ramach puli pamięci. Płyty były następnie dalej podzielone na 4 KB bloki, które były używane Kestrel wewnętrznie. Płyty musiały być większe niż 85 KB, aby wymusić alokację na dużym stercie obiektu, aby spróbować zapobiec przeniesieniu tej tablicy przez GC. Jednak wraz z wprowadzeniem nowej generacji GC, Przypięty sterta obiektów (POH), nie ma już sensu przydzielać bloków na płyty. Kestrel teraz bezpośrednio przydziela bloki na poH, co zmniejsza złożoność związaną z zarządzaniem pulą pamięci. Ta zmiana powinna ułatwić wykonywanie przyszłych ulepszeń, takich jak ułatwienie zmniejszenia puli pamięci używanej przez Kestrelprogram .

Obsługiwana funkcja IAsyncDisposable

IAsyncDisposable Jest teraz dostępny dla kontrolerów, Razor stron i składników widoku. Wersje asynchroniczne zostały dodane do odpowiednich interfejsów w fabrykach i aktywatorach:

  • Nowe metody oferują domyślną implementację interfejsu, która deleguje do synchronicznej wersji i wywołuje metodę Dispose.
  • Implementacje zastępują domyślną implementację i obsługują usuwanie IAsyncDisposable implementacji.
  • Implementacje są preferowane IAsyncDisposable IDisposable , gdy oba interfejsy są implementowane.
  • Rozszerzenia muszą zastąpić nowe metody dołączone do obsługi IAsyncDisposable wystąpień.

IAsyncDisposable jest korzystne podczas pracy z:

  • Asynchroniczne wyliczenia, na przykład w strumieniach asynchronicznych.
  • Zasoby niezarządzane, które mają operacje we/wy intensywnie korzystające z zasobów do wydania.

Podczas implementowania tego interfejsu DisposeAsync użyj metody , aby zwolnić zasoby.

Rozważmy kontroler, który tworzy i używa klasy Utf8JsonWriter. Utf8JsonWriterIAsyncDisposable to zasób:

public class HomeController : Controller, IAsyncDisposable
{
    private Utf8JsonWriter? _jsonWriter;
    private readonly ILogger<HomeController> _logger;

    public HomeController(ILogger<HomeController> logger)
    {
        _logger = logger;
        _jsonWriter = new Utf8JsonWriter(new MemoryStream());
    }

IAsyncDisposablemusi implementować :DisposeAsync

public async ValueTask DisposeAsync()
{
    if (_jsonWriter is not null)
    {
        await _jsonWriter.DisposeAsync();
    }

    _jsonWriter = null;
}

Port Vcpkg dla SignalR klienta C++

Vcpkg to międzyplatformowy menedżer pakietów wiersza polecenia dla bibliotek C i C++. Niedawno dodaliśmy port, aby vcpkg dodać CMake natywną obsługę SignalR klienta C++. vcpkg działa również z programem MSBuild.

Klienta SignalR można dodać do projektu narzędzia CMake przy użyciu następującego fragmentu kodu, gdy plik vcpkg znajduje się w pliku łańcucha narzędzi:

find_package(microsoft-signalr CONFIG REQUIRED)
link_libraries(microsoft-signalr::microsoft-signalr)

W poprzednim fragmencie SignalR kodu klient języka C++ jest gotowy do użycia #include i używany w projekcie bez żadnej dodatkowej konfiguracji. Pełny przykład aplikacji języka C++, która korzysta z SignalR klienta języka C++, zobacz repozytorium halter73/SignalR-Client-Cpp-Sample .

Blazor

Zmiany szablonu projektu

Wprowadzono kilka zmian szablonu projektu dla Blazor aplikacji, w tym użycie Pages/_Layout.cshtml pliku dla zawartości układu, która pojawiła się w _Host.cshtml pliku dla wcześniejszych Blazor Server aplikacji. Zapoznaj się ze zmianami, tworząc aplikację na podstawie szablonu projektu w wersji 6.0 lub korzystając z źródła referencyjnego ASP.NET Core dla szablonów projektów:

Blazor WebAssembly Obsługa zależności natywnych

Blazor WebAssembly aplikacje mogą używać natywnych zależności utworzonych do uruchamiania w zestawie WebAssembly. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Blazor WebAssembly zależności natywne.

Kompilacja zestawu WebAssembly (AOT) i ponowne łączenie środowiska uruchomieniowego

Blazor WebAssembly program obsługuje kompilację przed czasem (AOT), w której można skompilować kod platformy .NET bezpośrednio do zestawu WebAssembly. Kompilacja AOT powoduje zwiększenie wydajności środowiska uruchomieniowego kosztem większego rozmiaru aplikacji. Ponowne łączenie środowiska uruchomieniowego zestawu WebAssembly platformy .NET powoduje przycinanie nieużywanego kodu środowiska uruchomieniowego, co zwiększa szybkość pobierania. Aby uzyskać więcej informacji, zobacz Kompilacja przed czasem (AOT) i ponowne łączenie środowiska uruchomieniowego.

Utrwalanie stanu wstępnego

Blazor obsługuje stan utrwalania na stronie wstępnie wstępnie w taki sposób, aby stan nie musiał zostać utworzony ponownie po pełnym załadowaniu aplikacji. Aby uzyskać więcej informacji, zobacz Prerender i integrowanie składników ASP.NET CoreRazor.

Granice błędów

Granice błędów zapewniają wygodne podejście do obsługi wyjątków na poziomie interfejsu użytkownika. Aby uzyskać więcej informacji, zobacz Handle errors in ASP.NET Core apps (Obsługa błędów w aplikacjach platformy ASP.NET CoreBlazor).

Obsługa svG

Element <foreignObject> elementu jest obsługiwany do wyświetlania dowolnego kodu HTML w pliku SVG. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Blazor Serverobsługa transferu tablic bajtowych w międzyoperacie JS

Blazor obsługuje zoptymalizowane międzyoperacyjności tablicy JS bajtów, które unikają kodowania i dekodowania tablic bajtowych do base64. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Ulepszenia ciągu zapytania

Ulepszono obsługę pracy z ciągami zapytań. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor routing i nawigacja.

Wiązanie w celu wybrania wielu

Powiązanie obsługuje wybór wielu opcji z elementami <input> . Aby uzyskać więcej informacji, zobacz następujące zasoby:

Kontrolka zawartości head (<head>)

Razor składniki mogą modyfikować zawartość elementu HTML <head> strony, w tym ustawiać tytuł strony (<title> element) i modyfikować metadane (<meta> elementy). Aby uzyskać więcej informacji, zobacz Kontrolowanie <head> zawartości w aplikacjach ASP.NET CoreBlazor.

Generowanie składników platform Angular i React

Generowanie składników JavaScript specyficznych dla platformy na podstawie Razor składników dla platform internetowych, takich jak Angular lub React. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Renderowanie składników z poziomu języka JavaScript

Dynamiczne renderowanie Razor składników z języka JavaScript dla istniejących aplikacji JavaScript. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Elementy niestandardowe

Obsługa eksperymentalna jest dostępna do tworzenia elementów niestandardowych, które używają standardowych interfejsów HTML. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Wnioskowanie typów ogólnych składników ze składników modułu ancestor

Składnik przodka może kaskadowo użyć parametru typu według nazwy elementów potomnych przy użyciu nowego [CascadingTypeParameter] atrybutu. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Składniki renderowane dynamicznie

Użyj nowego wbudowanego DynamicComponent składnika do renderowania składników według typu. Aby uzyskać więcej informacji, zobacz Dynamiczne renderowanie składników ASP.NET CoreRazor.

Ulepszona Blazor dostępność

Użyj nowego FocusOnNavigate składnika, aby ustawić fokus interfejsu użytkownika na element oparty na selektorze CSS po przejściu z jednej strony do innej. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor routing i nawigacja.

Obsługa niestandardowego argumentu zdarzenia

Blazor Obsługuje niestandardowe argumenty zdarzeń, które umożliwiają przekazywanie dowolnych danych do programów obsługi zdarzeń platformy .NET z niestandardowymi zdarzeniami. Aby uzyskać więcej informacji, zobacz obsługa zdarzeń ASP.NET CoreBlazor.

Parametry wymagane

Zastosuj nowy [EditorRequired] atrybut, aby określić wymagany parametr składnika. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Kolokacja plików JavaScript ze stronami, widokami i składnikami

Sortowanie plików JavaScript dla stron, widoków i Razor składników jako wygodnego sposobu organizowania skryptów w aplikacji. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor JavaScript interoperability (JS interop).

Inicjatory języka JavaScript

Inicjatory języka JavaScript wykonują logikę przed załadowaniem aplikacji i po jej załadowaniu Blazor . Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor JavaScript interoperability (JS interop).

Przesyłanie strumieniowe międzyoperacyjnego kodu JavaScript

Blazor teraz obsługuje przesyłanie strumieniowe danych bezpośrednio między platformą .NET i językiem JavaScript. Aby uzyskać więcej informacji, zobacz następujące zasoby:

Ograniczenia typu ogólnego

Parametry typu ogólnego są teraz obsługiwane. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Razor składniki.

Układ wdrożenia zestawu WebAssembly

Użyj układu wdrożenia, aby włączyć Blazor WebAssembly pobieranie aplikacji w środowiskach zabezpieczeń z ograniczeniami. Aby uzyskać więcej informacji, zobacz Układ wdrażania dla aplikacji hostowanych Blazor WebAssembly ASP.NET Core.

Nowe Blazor artykuły

Oprócz Blazor funkcji opisanych w poprzednich sekcjach nowe Blazor artykuły są dostępne w następujących tematach:

Tworzenie Blazor Hybrid aplikacji za pomocą .NET MAUIsystemów , WPF i Windows Forms

Służy Blazor Hybrid do mieszania klasycznych i mobilnych natywnych struktur klienta z platformami .NET i Blazor:

  • .NET Multi-platform App UI (.NET MAUI) to międzyplatformowa struktura do tworzenia natywnych aplikacji mobilnych i klasycznych przy użyciu języków C# i XAML.
  • Blazor Hybrid aplikacje można tworzyć za pomocą platform Windows Presentation Foundation (WPF) i Windows Forms.

Ważne

Blazor Hybrid program jest w wersji zapoznawczej i nie powinien być używany w aplikacjach produkcyjnych do czasu wydania końcowego.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Kestrel

Protokół HTTP/3 jest obecnie w wersji roboczej i dlatego może ulec zmianie. Obsługa protokołu HTTP/3 w programie ASP.NET Core nie została wydana. Jest to funkcja w wersji zapoznawczej dostępna na platformie .NET 6.

Kestrel obsługuje teraz protokół HTTP/3. Aby uzyskać więcej informacji, zobacz Use HTTP/3 with the ASP.NET Core web server and the blog entry HTTP/3 support in .NET 6 (Używanie protokołu HTTP/3 z serwerem internetowym platformy ASP.NET CoreKestrel) i wpisem w blogu http/3 support in .NET 6 (Obsługa protokołu HTTP/3 w witrynie .NET 6).

Nowe Kestrel kategorie rejestrowania dla wybranego rejestrowania

Przed tą zmianą włączenie pełnego rejestrowania było Kestrel zbyt kosztowne, ponieważ wszystkie nazwy kategorii rejestrowania Kestrel Microsoft.AspNetCore.Server.Kestrel były zbyt kosztowne. Microsoft.AspNetCore.Server.Kestrel jest nadal dostępna, ale następujące nowe podkategorie umożliwiają większą kontrolę nad rejestrowaniem:

  • Microsoft.AspNetCore.Server.Kestrel(bieżąca kategoria): ApplicationError, , . RequestBodyDoneHeartbeatSlowConnectionHeadResponseBodyWriteApplicationNeverCompletedRequestBodyStartRequestBodyNotEntirelyReadRequestBodyDrainTimedOutResponseMinimumDataRateNotSatisfiedInvalidResponseHeaderRemoved
  • Microsoft.AspNetCore.Server.Kestrel.BadRequests: ConnectionBadRequest, RequestProcessingError, RequestBodyMinimumDataRateNotSatisfied.
  • Microsoft.AspNetCore.Server.Kestrel.Connections: ConnectionAccepted, , ConnectionStopConnectionStartApplicationAbortedConnectionNotAllConnectionsAbortedConnectionDisconnectConnectionKeepAliveNotAllConnectionsClosedGracefullyConnectionPauseConnectionResumeConnectionRejected.
  • Microsoft.AspNetCore.Server.Kestrel.Http2: Http2ConnectionError, , Http2ConnectionClosedHPackDecodingErrorHttp2StreamErrorHttp2ConnectionClosingHPackEncodingErrorHttp2FrameReceivedHttp2StreamResetAbort, Http2FrameSending, . Http2MaxConcurrentStreamsReached
  • Microsoft.AspNetCore.Server.Kestrel.Http3: Http3ConnectionError, , Http3ConnectionClosing, Http3StreamAbortHttp3ConnectionClosed, Http3FrameReceived, . Http3FrameSending

Istniejące reguły nadal działają, ale teraz możesz być bardziej selektywne, na których regułach można włączyć. Na przykład zauważalne obciążenie związane z włączaniem Debug rejestrowania tylko nieprawidłowych żądań jest znacznie zmniejszone i można je włączyć przy użyciu następującej konfiguracji:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.AspNetCore.Kestrel.BadRequests": "Debug"
    }
  }

Filtrowanie dzienników stosuje reguły z najdłuższym pasującym prefiksem kategorii. Aby uzyskać więcej informacji, zobacz Jak są stosowane reguły filtrowania

Emituj zdarzenie KestrelServerOptions za pośrednictwem zdarzenia EventSource

Element KestrelEventSource emituje nowe zdarzenie zawierające serializację KestrelServerOptions JSON, gdy jest włączone z szczegółowością EventLevel.LogAlways. To zdarzenie ułatwia wnioskowanie o zachowaniu serwera podczas analizowania zebranych śladów. Poniższy kod JSON jest przykładem ładunku zdarzenia:

{
  "AllowSynchronousIO": false,
  "AddServerHeader": true,
  "AllowAlternateSchemes": false,
  "AllowResponseHeaderCompression": true,
  "EnableAltSvc": false,
  "IsDevCertLoaded": true,
  "RequestHeaderEncodingSelector": "default",
  "ResponseHeaderEncodingSelector": "default",
  "Limits": {
    "KeepAliveTimeout": "00:02:10",
    "MaxConcurrentConnections": null,
    "MaxConcurrentUpgradedConnections": null,
    "MaxRequestBodySize": 30000000,
    "MaxRequestBufferSize": 1048576,
    "MaxRequestHeaderCount": 100,
    "MaxRequestHeadersTotalSize": 32768,
    "MaxRequestLineSize": 8192,
    "MaxResponseBufferSize": 65536,
    "MinRequestBodyDataRate": "Bytes per second: 240, Grace Period: 00:00:05",
    "MinResponseDataRate": "Bytes per second: 240, Grace Period: 00:00:05",
    "RequestHeadersTimeout": "00:00:30",
    "Http2": {
      "MaxStreamsPerConnection": 100,
      "HeaderTableSize": 4096,
      "MaxFrameSize": 16384,
      "MaxRequestHeaderFieldSize": 16384,
      "InitialConnectionWindowSize": 131072,
      "InitialStreamWindowSize": 98304,
      "KeepAlivePingDelay": "10675199.02:48:05.4775807",
      "KeepAlivePingTimeout": "00:00:20"
    },
    "Http3": {
      "HeaderTableSize": 0,
      "MaxRequestHeaderFieldSize": 16384
    }
  },
  "ListenOptions": [
    {
      "Address": "https://127.0.0.1:7030",
      "IsTls": true,
      "Protocols": "Http1AndHttp2"
    },
    {
      "Address": "https://[::1]:7030",
      "IsTls": true,
      "Protocols": "Http1AndHttp2"
    },
    {
      "Address": "http://127.0.0.1:5030",
      "IsTls": false,
      "Protocols": "Http1AndHttp2"
    },
    {
      "Address": "http://[::1]:5030",
      "IsTls": false,
      "Protocols": "Http1AndHttp2"
    }
  ]
}

Nowe zdarzenie DiagnosticSource dla odrzuconych żądań HTTP

Kestrel teraz emituje nowe DiagnosticSource zdarzenie dla żądań HTTP odrzuconych w warstwie serwera. Przed tą zmianą nie było możliwości obserwowania tych odrzuconych żądań. Nowe DiagnosticSource zdarzenie Microsoft.AspNetCore.Server.Kestrel.BadRequest zawiera element IBadRequestExceptionFeature , który może służyć do introspekcja przyczyny odrzucenia żądania.

using Microsoft.AspNetCore.Http.Features;
using System.Diagnostics;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
var diagnosticSource = app.Services.GetRequiredService<DiagnosticListener>();
using var badRequestListener = new BadRequestEventListener(diagnosticSource,
    (badRequestExceptionFeature) =>
{
    app.Logger.LogError(badRequestExceptionFeature.Error, "Bad request received");
});
app.MapGet("/", () => "Hello world");

app.Run();

class BadRequestEventListener : IObserver<KeyValuePair<string, object>>, IDisposable
{
    private readonly IDisposable _subscription;
    private readonly Action<IBadRequestExceptionFeature> _callback;

    public BadRequestEventListener(DiagnosticListener diagnosticListener,
                                   Action<IBadRequestExceptionFeature> callback)
    {
        _subscription = diagnosticListener.Subscribe(this!, IsEnabled);
        _callback = callback;
    }
    private static readonly Predicate<string> IsEnabled = (provider) => provider switch
    {
        "Microsoft.AspNetCore.Server.Kestrel.BadRequest" => true,
        _ => false
    };
    public void OnNext(KeyValuePair<string, object> pair)
    {
        if (pair.Value is IFeatureCollection featureCollection)
        {
            var badRequestFeature = featureCollection.Get<IBadRequestExceptionFeature>();

            if (badRequestFeature is not null)
            {
                _callback(badRequestFeature);
            }
        }
    }
    public void OnError(Exception error) { }
    public void OnCompleted() { }
    public virtual void Dispose() => _subscription.Dispose();
}

Aby uzyskać więcej informacji, zobacz Rejestrowanie i diagnostyka w programie Kestrel.

Tworzenie obiektu ConnectionContext na podstawie gniazda Accept

Nowe SocketConnectionContextFactory umożliwia utworzenie obiektu ConnectionContext na podstawie zaakceptowanego gniazda. Dzięki temu można utworzyć niestandardowe gniazdo oparte IConnectionListenerFactory na gniazdach bez utraty wszystkich zadań związanych z wydajnością i puli odbywających się w programie SocketConnection.

Zobacz ten przykład niestandardowego elementu IConnectionListenerFactory , który pokazuje, jak używać tego elementu SocketConnectionContextFactory.

Kestrel jest domyślnym profilem uruchamiania programu Visual Studio

Domyślny profil uruchamiania dla wszystkich nowych projektów internetowych dotnet to Kestrel. Uruchamianie Kestrel jest znacznie szybsze i skutkuje bardziej dynamicznym środowiskiem podczas tworzenia aplikacji.

Usługi IIS Express są nadal dostępne jako profil uruchamiania dla scenariuszy, takich jak uwierzytelnianie systemu Windows lub udostępnianie portów.

Porty hosta lokalnego dla Kestrel są losowe

Aby uzyskać więcej informacji, zobacz Porty wygenerowane przez szablon dla Kestrel tego dokumentu.

Uwierzytelnianie i autoryzacja

Serwery uwierzytelniania

Platforma .NET 3 do platformy .NET 5 używała serwera IdentityServer4 w ramach naszego szablonu do obsługi wystawiania tokenów JWT dla SPA i Blazor aplikacji. Szablony używają teraz serwera DuendeIdentity.

Jeśli rozszerzasz identity modele i aktualizujesz istniejące projekty, zaktualizuj przestrzenie nazw w kodzie z do i Duende.IdentityServer postępuj zgodnie z IdentityServer4.IdentityServer instrukcjami migracji.

Model licencji dla serwera Duende Identity został zmieniony na wzajemną licencję, która może wymagać opłat licencyjnych, gdy jest używana komercyjnie w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz stronę licencji Duende.

Opóźnione negocjowanie certyfikatu klienta

Deweloperzy mogą teraz wyrazić zgodę na korzystanie z opóźnionych negocjacji certyfikatu klienta, określając wartość ClientCertificateMode.DelayCertificate w pliku HttpsConnectionAdapterOptions. Działa to tylko z połączeniami HTTP/1.1, ponieważ protokół HTTP/2 zabrania opóźnionej renegocjacji certyfikatu. Obiekt wywołujący tego interfejsu API musi buforować treść żądania przed zażądaniem certyfikatu klienta:

using Microsoft.AspNetCore.Server.Kestrel.Https;
using Microsoft.AspNetCore.WebUtilities;

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseKestrel(options =>
{
    options.ConfigureHttpsDefaults(adapterOptions =>
    {
        adapterOptions.ClientCertificateMode = ClientCertificateMode.DelayCertificate;
    });
});

var app = builder.Build();
app.Use(async (context, next) =>
{
    bool desiredState = GetDesiredState();
    // Check if your desired criteria is met
    if (desiredState)
    {
        // Buffer the request body
        context.Request.EnableBuffering();
        var body = context.Request.Body;
        await body.DrainAsync(context.RequestAborted);
        body.Position = 0;

        // Request client certificate
        var cert = await context.Connection.GetClientCertificateAsync();

        //  Disable buffering on future requests if the client doesn't provide a cert
    }
    await next(context);
});


app.MapGet("/", () => "Hello World!");
app.Run();

Cookie Możliwość dostosowywania lub pomijania uwierzytelniania przy użyciu nowego OnCheckSlidingExpirationelementu . Na przykład to zdarzenie może być używane przez aplikację jednostronicową, która musi okresowo wysyłać polecenia ping do serwera bez wpływu na sesję uwierzytelniania.

Różne

Gorące ponowne ładowanie

Szybkie wprowadzanie aktualizacji interfejsu użytkownika i kodu do uruchomionych aplikacji bez utraty stanu aplikacji w celu szybszego i bardziej wydajnego środowiska deweloperów przy użyciu Przeładowywanie na gorąco. Aby uzyskać więcej informacji, zobacz Obsługa platformy .NET Przeładowywanie na gorąco dla platformy ASP.NET Core i Update on .NET Przeładowywanie na gorąco progress (Postęp Przeładowywanie na gorąco platformy .NET) i Visual Studio 2022 Highlights (Najważniejsze informacje na temat programu Visual Studio 2022).

Ulepszone szablony aplikacji jednostronicowej (SPA)

Szablony projektów platformy ASP.NET Core zostały zaktualizowane dla platformy Angular i React w celu użycia ulepszonego wzorca dla aplikacji jednostronicowych, które są bardziej elastyczne i ściśle dopasowane do typowych wzorców nowoczesnego tworzenia aplikacji internetowych frontonu.

Wcześniej szablon ASP.NET Core dla platformy Angular i React używał wyspecjalizowanego oprogramowania pośredniczącego podczas programowania w celu uruchomienia serwera programistycznego dla platformy frontonu, a następnie żądań serwera proxy z ASP.NET Core na serwer deweloperów. Logika uruchamiania serwera programistycznego frontonu była specyficzna dla interfejsu wiersza polecenia dla odpowiedniej struktury frontonu. Obsługa dodatkowych struktur frontonu przy użyciu tego wzorca oznaczała dodanie dodatkowej logiki do platformy ASP.NET Core.

Zaktualizowane szablony platformy ASP.NET Core dla platform Angular i React na platformie .NET 6 przerzucają ten układ i korzystają z wbudowanej obsługi serwera proxy na serwerach deweloperskich najbardziej nowoczesnych struktur frontonu. Po uruchomieniu aplikacji ASP.NET Core serwer deweloperów frontonu jest uruchamiany tak jak wcześniej, ale serwer deweloperów jest skonfigurowany do obsługi żądań serwera proxy do procesu zaplecza ASP.NET Core. Cała konfiguracja specyficzna dla frontonu do konfigurowania serwera proxy jest częścią aplikacji, a nie ASP.NET Core. Konfigurowanie projektów ASP.NET Core do pracy z innymi strukturami frontonu jest teraz proste: konfigurowanie serwera deweloperów frontonu dla wybranej platformy do serwera proxy do zaplecza ASP.NET Core przy użyciu wzorca ustanowionego w szablonach Platformy Angular i React.

Kod uruchamiania aplikacji ASP.NET Core nie potrzebuje już żadnej logiki specyficznej dla aplikacji jednostronicowej. Logika uruchamiania serwera programistycznego frontonu podczas programowania jest wstrzykiwana do aplikacji w czasie wykonywania przez nowy pakiet Microsoft.AspNetCore.SpaProxy . Routing rezerwowy jest obsługiwany przy użyciu routingu punktów końcowych zamiast oprogramowania pośredniczącego specyficznego dla SPA.

Szablony zgodne z tym wzorcem mogą być nadal uruchamiane jako pojedynczy projekt w programie Visual Studio lub z dotnet run poziomu wiersza polecenia. Po opublikowaniu aplikacji kod frontonu w folderze ClientApp jest kompilowany i zbierany tak jak wcześniej w katalogu głównym internetowym aplikacji ASP.NET Core hosta i służył jako pliki statyczne. Skrypty zawarte w szablonie umożliwiają skonfigurowanie serwera programistycznego frontonu do używania protokołu HTTPS przy użyciu certyfikatu dewelopera ASP.NET Core.

Obsługa protokołu HTTP/3 w wersji roboczej na platformie .NET 6

Protokół HTTP/3 jest obecnie w wersji roboczej i dlatego może ulec zmianie. Obsługa protokołu HTTP/3 w programie ASP.NET Core nie została wydana. Jest to funkcja w wersji zapoznawczej dostępna na platformie .NET 6.

Zobacz wpis w blogu Obsługa protokołu HTTP/3 na platformie .NET 6.

Adnotacje typu odwołania dopuszczanego do wartości null

Części kodu źródłowego platformy ASP.NET Core 6.0 miały zastosowane adnotacje o wartości null.

Korzystając z nowej funkcji dopuszczającej wartość null w języku C# 8, ASP.NET Core może zapewnić dodatkowe bezpieczeństwo czasu kompilacji w obsłudze typów odwołań. Na przykład ochrona przed wyjątkami referencyjnymi null . Projekty, które zdecydowały się na używanie adnotacji dopuszczających wartość null, mogą wyświetlać nowe ostrzeżenia dotyczące czasu kompilacji z interfejsów API platformy ASP.NET Core.

Aby włączyć typy referencyjne dopuszczane do wartości null, dodaj następującą właściwość do plików projektu:

<PropertyGroup>
    <Nullable>enable</Nullable>
</PropertyGroup>

Aby uzyskać więcej informacji, zobacz Typy referencyjne dopuszczane do wartości null.

Analiza kodu źródłowego

Dodano kilka analizatorów platformy kompilatora .NET, które sprawdzają kod aplikacji pod kątem problemów, takich jak nieprawidłowa konfiguracja oprogramowania pośredniczącego lub kolejność, konflikty routingu itp. Aby uzyskać więcej informacji, zobacz Analiza kodu w aplikacjach platformy ASP.NET Core.

Ulepszenia szablonu aplikacji internetowej

Szablony aplikacji internetowej:

Porty wygenerowane przez szablon dla Kestrel

Losowe porty są przypisywane podczas tworzenia projektu do użytku przez Kestrel serwer internetowy. Losowe porty pomagają zminimalizować konflikt portów, gdy wiele projektów jest uruchamianych na tej samej maszynie.

Po utworzeniu projektu losowy port HTTP z zakresu od 5000 do 5300 i losowego portu HTTPS z zakresu od 7000 do 7300 jest określony w wygenerowanym Properties/launchSettings.json pliku. Porty można zmienić w Properties/launchSettings.json pliku. Jeśli nie określono portu, Kestrel domyślnie są używane porty HTTP 5000 i HTTPS 5001. Aby uzyskać więcej informacji, zobacz Konfigurowanie punktów końcowych dla serwera internetowego ASP.NET CoreKestrel.

Nowe wartości domyślne rejestrowania

Wprowadzono następujące zmiany w systemach appsettings.json i appsettings.Development.json:

- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"

Zmiana z "Microsoft": "Warning" na powoduje rejestrowanie wszystkich komunikatów informacyjnych z przestrzeni nazw z Microsoft wyjątkiemMicrosoft.AspNetCore ."Microsoft.AspNetCore": "Warning" Na przykład Microsoft.EntityFrameworkCore jest teraz rejestrowany na poziomie informacyjnym.

Strona wyjątku dla deweloperów — oprogramowanie pośredniczące dodane automatycznie

W środowiskuDeveloperExceptionPageMiddleware deweloperów element jest domyślnie dodawany. Dodanie następującego kodu do aplikacji internetowego interfejsu użytkownika nie jest już konieczne:

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

Obsługa nagłówków żądań zakodowanych w formacie Latin1 na serwerze HttpSysServer

HttpSysServer Teraz obsługuje dekodowanie nagłówków żądań zakodowanych Latin1 przez ustawienie UseLatin1RequestHeaders właściwości na HttpSysOptions wartość true:

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseHttpSys(o => o.UseLatin1RequestHeaders = true);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Dzienniki modułu podstawowego ASP.NET obejmują znaczniki czasu i identyfikator PID

Rozszerzone dzienniki diagnostyczne modułu ASP.NET Core Module (ANCM) dla usług IIS (ANCM) obejmują znaczniki czasu i identyfikator PID procesu emitujące dzienniki. Rejestrowanie sygnatur czasowych i piD ułatwia diagnozowanie problemów z nakładającymi się ponownymi uruchomieniami procesów w usługach IIS, gdy są uruchomione wiele procesów roboczych usług IIS.

Wynikowe dzienniki są teraz podobne do przykładowych danych wyjściowych pokazanych poniżej:

[2021-07-28T19:23:44.076Z, PID: 11020] [aspnetcorev2.dll] Initializing logs for 'C:\<path>\aspnetcorev2.dll'. Process Id: 11020. File Version: 16.0.21209.0. Description: IIS ASP.NET Core Module V2. Commit: 96475a2acdf50d7599ba8e96583fa73efbe27912.
[2021-07-28T19:23:44.079Z, PID: 11020] [aspnetcorev2.dll] Resolving hostfxr parameters for application: '.\InProcessWebSite.exe' arguments: '' path: 'C:\Temp\e86ac4e9ced24bb6bacf1a9415e70753\'
[2021-07-28T19:23:44.080Z, PID: 11020] [aspnetcorev2.dll] Known dotnet.exe location: ''

Konfigurowalny niekonsumowany rozmiar buforu przychodzącego dla usług IIS

Serwer usług IIS buforował wcześniej tylko 64 KiB nieskonsumowanych treści żądań. Buforowanie 64 KiB spowodowało ograniczenie odczytu do tego maksymalnego rozmiaru, co ma wpływ na wydajność z dużymi ciałami przychodzącymi, takimi jak przekazywanie. Na platformie .NET 6 domyślny rozmiar buforu zmienia się z 64 KiB na 1 MiB, co powinno poprawić przepływność dużych przekazywania. W naszych testach przekazywanie 700 MiB, które zajęło 9 sekund, trwa teraz tylko 2,5 sekundy.

Wadą większego rozmiaru buforu jest zwiększenie użycia pamięci na żądanie, gdy aplikacja nie odczytuje szybko treści żądania. Dlatego oprócz zmiany domyślnego rozmiaru buforu można skonfigurować rozmiar buforu, umożliwiając aplikacjom konfigurowanie rozmiaru buforu na podstawie obciążenia.

Wyświetlanie pomocników tagów składników

Rozważ składnik widoku z opcjonalnym parametrem, jak pokazano w poniższym kodzie:

class MyViewComponent
{
    IViewComponentResult Invoke(bool showSomething = false) { ... }
}

Przy ASP.NET Core 6 można wywołać pomocnika tagów bez konieczności określania wartości parametru showSomething :

<vc:my />

Szablon angular zaktualizowany do platformy Angular 12

Szablon ASP.NET Core 6.0 dla platformy Angular używa teraz platformy Angular 12.

Szablon React został zaktualizowany do platformy React 17.

Konfigurowalny próg buforu przed zapisem na dysku w Json.NET formacie wyjściowym

Uwaga: zalecamy używanie formatera danych wyjściowych z System.Text.Json wyjątkiem sytuacji, gdy Newtonsoft.Json serializator jest wymagany ze względów zgodności. System.Text.Json Serializator jest w pełni async i działa wydajnie w przypadku większych ładunków.

Formater Newtonsoft.Json danych wyjściowych domyślnie buforuje odpowiedzi do 32 KiB w pamięci przed buforowaniem na dysku. Należy unikać wykonywania synchronicznych operacji we/wy, co może spowodować inne skutki uboczne, takie jak głodowanie wątków i zakleszczenia aplikacji. Jeśli jednak odpowiedź jest większa niż 32 KiB, występuje znaczna ilość operacji we/wy dysku. Próg pamięci można teraz skonfigurować za pomocą właściwości MvcNewtonsoftJsonOptions.OutputFormatterMemoryBufferThreshold przed buforowaniem na dysku:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages()
            .AddNewtonsoftJson(options =>
            { 
                options.OutputFormatterMemoryBufferThreshold = 48 * 1024;
            });

var app = builder.Build();

Aby uzyskać więcej informacji, zobacz to żądanie ściągnięcia w usłudze GitHub i plik NewtonsoftJsonOutputFormatterTest.cs .

Szybsze pobieranie i ustawianie nagłówków HTTP

Dodano nowe interfejsy API, aby uwidocznić wszystkie typowe nagłówki dostępne Microsoft.Net.Http.Headers.HeaderNames jako właściwości IHeaderDictionary w celu ułatwienia korzystania z interfejsu API. Na przykład oprogramowanie pośredniczące w wierszu w poniższym kodzie pobiera i ustawia nagłówki żądań i odpowiedzi przy użyciu nowych interfejsów API:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Use(async (context, next) =>
{
    var hostHeader = context.Request.Headers.Host;
    app.Logger.LogInformation("Host header: {host}", hostHeader);
    context.Response.Headers.XPoweredBy = "ASP.NET Core 6.0";
    await next.Invoke(context);
    var dateHeader = context.Response.Headers.Date;
    app.Logger.LogInformation("Response date: {date}", dateHeader);
});

app.Run();

W przypadku zaimplementowanych nagłówków metody uzyskiwania i ustawiania metod dostępu są implementowane bezpośrednio do pola i pomijając wyszukiwanie. W przypadku nagłówków, które nie zostały zaimplementowane, metody dostępu mogą pominąć początkowe wyszukiwanie względem zaimplementowanych nagłówków i bezpośrednio wykonać Dictionary<string, StringValues> wyszukiwanie. Unikanie wyszukiwania skutkuje szybszym dostępem w obu scenariuszach.

Asynchroniczne przesyłanie strumieniowe

ASP.NET Core obsługuje teraz asynchroniczne przesyłanie strumieniowe z akcji kontrolera i odpowiedzi z formatera JSON. Zwracanie IAsyncEnumerable elementu z akcji nie buforuje już zawartości odpowiedzi w pamięci przed wysłaniem. Buforowanie nie pomaga zmniejszyć użycia pamięci podczas zwracania dużych zestawów danych, które mogą być wyliczane asynchronicznie.

Należy pamiętać, że program Entity Framework Core udostępnia implementacje IAsyncEnumerable do wykonywania zapytań dotyczących bazy danych. Ulepszona obsługa IAsyncEnumerable platformy ASP.NET Core na platformie .NET 6 może zwiększyć wydajność korzystania EF Core z platformy ASP.NET Core. Na przykład poniższy kod nie buforuje już danych produktu do pamięci przed wysłaniem odpowiedzi:

public IActionResult GetMovies()
{
    return Ok(_context.Movie);
}

Jednak w przypadku korzystania z ładowania z opóźnieniem w EF Coreprogramie to nowe zachowanie może spowodować błędy z powodu współbieżnego wykonywania zapytań podczas wyliczania danych. Aplikacje mogą wrócić do poprzedniego zachowania, buforując dane:

public async Task<IActionResult> GetMovies2()
{
    return Ok(await _context.Movie.ToListAsync());
}

Zapoznaj się z powiązanym ogłoszeniem, aby uzyskać dodatkowe szczegóły dotyczące tej zmiany zachowania.

Oprogramowanie pośredniczące rejestrowania HTTP

Rejestrowanie HTTP to nowe wbudowane oprogramowanie pośredniczące, które rejestruje informacje o żądaniach HTTP i odpowiedziach HTTP, w tym nagłówków i całej treści:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();
app.UseHttpLogging();

app.MapGet("/", () => "Hello World!");

app.Run();

Przejdź do strony z poprzednim kodem, aby / uzyskać informacje podobne do następujących danych wyjściowych:

info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[1]
      Request:
      Protocol: HTTP/2
      Method: GET
      Scheme: https
      PathBase: 
      Path: /
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
      Accept-Encoding: gzip, deflate, br
      Accept-Language: en-US,en;q=0.9
      Cache-Control: max-age=0
      Connection: close
      Cookie: [Redacted]
      Host: localhost:44372
      User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36 Edg/95.0.1020.30
      sec-ch-ua: [Redacted]
      sec-ch-ua-mobile: [Redacted]
      sec-ch-ua-platform: [Redacted]
      upgrade-insecure-requests: [Redacted]
      sec-fetch-site: [Redacted]
      sec-fetch-mode: [Redacted]
      sec-fetch-user: [Redacted]
      sec-fetch-dest: [Redacted]
info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[2]
      Response:
      StatusCode: 200
      Content-Type: text/plain; charset=utf-8

Powyższe dane wyjściowe zostały włączone z następującym appsettings.Development.json plikiem:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
    }
  }
}

Rejestrowanie HTTP udostępnia dzienniki zawierające:

  • Informacje o żądaniu HTTP
  • Wspólne właściwości
  • Nagłówki
  • Treść
  • Informacje o odpowiedzi HTTP

Aby skonfigurować oprogramowanie pośredniczące rejestrowania HTTP, określ polecenie HttpLoggingOptions:

using Microsoft.AspNetCore.HttpLogging;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpLogging(logging =>
{
    // Customize HTTP logging.
    logging.LoggingFields = HttpLoggingFields.All;
    logging.RequestHeaders.Add("My-Request-Header");
    logging.ResponseHeaders.Add("My-Response-Header");
    logging.MediaTypeOptions.AddText("application/javascript");
    logging.RequestBodyLogLimit = 4096;
    logging.ResponseBodyLogLimit = 4096;
});

var app = builder.Build();
app.UseHttpLogging();

app.MapGet("/", () => "Hello World!");

app.Run();

IConnectionSocketFeature

Funkcja IConnectionSocketFeature żądania zapewnia dostęp do bazowego gniazda akceptowania skojarzonego z bieżącym żądaniem. Dostęp do niego można uzyskać za pośrednictwem adresu w witrynie FeatureCollection HttpContext.

Na przykład następująca aplikacja ustawia LingerState właściwość w zaakceptowanym gniazdie:

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureEndpointDefaults(listenOptions => listenOptions.Use((connection, next) =>
    {
        var socketFeature = connection.Features.Get<IConnectionSocketFeature>();
        socketFeature.Socket.LingerState = new LingerOption(true, seconds: 10);
        return next();
    }));
});
var app = builder.Build();
app.MapGet("/", (Func<string>)(() => "Hello world"));
await app.RunAsync();

Ograniczenia typu ogólnego w systemie Razor

Podczas definiowania ogólnych parametrów typu w Razor @typeparam dyrektywie można teraz określić ograniczenia typów ogólnych przy użyciu standardowej składni języka C#:

Mniejsze SignalRskrypty , Blazor Serveri MessagePack

Skrypty SignalR, MessagePack i Blazor Server MessagePack są teraz znacznie mniejsze, umożliwiając mniejsze pobieranie, mniej analizowania i kompilowania kodu JavaScript przez przeglądarkę oraz szybsze uruchamianie. Zmniejszenie rozmiaru:

  • signalr.js: 70%
  • blazor.server.js: 45%

Mniejsze skrypty są wynikiem udziału społeczności Ben Adams. Aby uzyskać więcej informacji na temat szczegółów redukcji rozmiaru, zobacz Żądanie ściągnięcia Usługi GitHub Ben.

Włączanie sesji profilowania usługi Redis

Współtworzenie przez społeczność gabriela Lucaci umożliwia sesję profilowania usługi Redis za pomocą biblioteki Microsoft.Extensions.Caching.StackExchangeRedis:

using StackExchange.Redis.Profiling;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.ProfilingSession = () => new ProfilingSession();
});

Aby uzyskać więcej informacji, zobacz StackExchange.Redis Profilowanie.

Kopiowanie w tle w usługach IIS

Funkcja eksperymentalna została dodana do modułu ASP.NET Core Module (ANCM) dla usług IIS w celu dodania obsługi zestawów aplikacji do kopiowania w tle. Obecnie platforma .NET blokuje pliki binarne aplikacji podczas uruchamiania w systemie Windows, co uniemożliwia zastąpienie plików binarnych podczas działania aplikacji. Chociaż naszym zaleceniem pozostaje użycie pliku offline aplikacji, uznajemy, że istnieją pewne scenariusze (na przykład wdrożenia FTP), w których nie jest to możliwe.

W takich scenariuszach włącz kopiowanie w tle, dostosowując ustawienia obsługi modułu ASP.NET Core. W większości przypadków aplikacje ASP.NET Core nie mają web.config zaewidencjonowane w kontroli źródła, którą można modyfikować. W ASP.NET Core web.config jest zwykle generowany przez zestaw SDK. Do rozpoczęcia pracy można użyć następującego przykładu web.config :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- To customize the asp.net core module uncomment and edit the following section. 
  For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->

  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
      <handlerSettings>
        <handlerSetting name="experimentalEnableShadowCopy" value="true" />
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
        <!-- Only enable handler logging if you encounter issues-->
        <!--<handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />-->
        <!--<handlerSetting name="debugLevel" value="FILE,TRACE" />-->
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>

Kopiowanie w tle w usługach IIS to funkcja eksperymentalna, która nie ma gwarancji, że jest częścią ASP.NET Core. Przekaż opinię na temat kopiowania w tle usług IIS w tym problemie z usługą GitHub.

Dodatkowe zasoby