Sdílet prostřednictvím

Novinky v ASP.NET Core 6.0

  • Článek

Tento článek popisuje nejvýznamnější změny v ASP.NET Core 6.0 s odkazy na příslušnou dokumentaci.

ASP.NET Core MVC a Razor vylepšení

Minimální rozhraní API

Minimální rozhraní API jsou navržena tak, aby vytvářela rozhraní HTTP API s minimálními závislostmi. Jsou ideální pro mikroslužby a aplikace, které chtějí do ASP.NET Core zahrnout jenom minimální soubory, funkce a závislosti. Další informace naleznete v tématu:

SignalR

Značka dlouhotrvající aktivity pro SignalR připojení

SignalR použije novou Microsoft.AspNetCore.Http.Features.IHttpActivityFeature.Activity k přidání http.long_running značky do aktivity požadavku. IHttpActivityFeature.Activityslužby APM, jako je Azure Monitor Application Insights, používají k filtrování SignalR požadavků z vytváření dlouho běžících upozornění požadavků.

SignalR vylepšení výkonu

  • Přidělit HubCallerClients jednou za připojení místo každé volání metody centra.
  • Vyhněte se přidělování uzavření v SignalRDefaultHubDispatcher.Invoke. Stav se předává místní statické funkci prostřednictvím parametrů, aby se zabránilo přidělení uzavření. Další informace najdete v této žádosti o přijetí změn na GitHubu.
  • Přidělte jeden StreamItemMessage datový proud místo položky datového proudu v streamování mezi klienty. Další informace najdete v této žádosti o přijetí změn na GitHubu.

Razor překladač

Razor Kompilátor byl aktualizován tak, aby používal generátory zdrojů.

Kompilátor Razor je teď založený na generátorech zdrojového kódu jazyka C#. Generátory zdrojů se spouští během kompilace a kontrolují, co se kompiluje, aby se vytvořily další soubory kompilované spolu s rest projektem. Použití generátorů zdrojů zjednodušuje Razor kompilátor a výrazně zrychluje časy sestavení.

Razor Kompilátor už nevytácí samostatné sestavení Zobrazení

Kompilátor Razor dříve využil dvoustupňový proces kompilace, který vytvořil samostatné sestavení Zobrazení, které obsahovalo vygenerovaná zobrazení a stránky (.cshtml soubory) definované v aplikaci. Generované typy byly veřejné a pod oborem AspNetCore názvů.

Aktualizovaný Razor kompilátor sestaví zobrazení a typy stránek do hlavního sestavení projektu. Tyto typy se teď ve výchozím nastavení generují jako vnitřní zapečetěné v AspNetCoreGeneratedDocument oboru názvů. Tato změna zlepšuje výkon sestavení, umožňuje nasazení jednoho souboru a umožňuje těmto typům účastnit se Opětovné načítání za provozu.

Další informace o této změně najdete v souvisejícím problému s oznámením na GitHubu.

Vylepšení výkonu a rozhraní API pro ASP.NET Core

Mnoho změn bylo provedeno za účelem snížení alokace a zvýšení výkonu v rámci zásobníku:

Menší nároky na paměť pro nečinná připojení TLS

U dlouhotrvajících připojení TLS, kdy se data odesílají jenom občas a zpět, výrazně jsme snížili nároky na paměť aplikací ASP.NET Core v .NET 6. To by mělo pomoct zlepšit škálovatelnost scénářů, jako jsou servery WebSocket. To bylo možné díky mnoha vylepšením System.IO.Pipelines, SslStreama Kestrel. Následující části obsahují podrobnosti o některých vylepšeních, která přispěla ke snížení využití paměti:

Zmenšení velikosti System.IO.Pipelines.Pipe

Pro každé vytvořené připojení jsou dva kanály přiděleny v Kestrel:

  • Přenosová vrstva do aplikace pro požadavek.
  • Aplikační vrstva do přenosu odpovědi.

Zmenšením velikosti System.IO.Pipelines.Pipe 368 bajtů na 264 bajtů (přibližně 28,2 % snížení), 208 bajtů na připojení se uloží (104 bajtů na potrubí).

Pool SocketSender

SocketSender objekty (podtřídy SocketAsyncEventArgs) jsou za běhu přibližně 350 bajtů. Místo přidělení nového SocketSender objektu na připojení je možné je vytvořit ve fondu. SocketSender objekty mohou být ve fondu, protože odesílání jsou obvykle velmi rychlé. Sdružování snižuje režijní náklady na připojení. Místo přidělení 350 bajtů na připojení je přiděleno pouze 350 bajtů na IOQueue jedno připojení. Přidělení se provádí pro každou frontu, aby nedocházelo ke kolizím. Náš server WebSocket s 5000 nečinnými připojeními šel od přidělení ~1,75 MB (350 bajtů * 5000) přidělení ~2,8 kb (350 bajtů * 8) pro SocketSender objekty.

Nulové bajty přečtené pomocí SslStreamu

Čtení bez vyrovnávací paměti je technika použitá v ASP.NET Core, aby se zabránilo zapůjčení paměti z fondu paměti, pokud v soketu nejsou k dispozici žádná data. Před touto změnou vyžaduje server WebSocket s 5000 nečinnými připojeními přibližně 200 MB bez protokolu TLS ve srovnání s protokolem TLS přibližně 800 MB. Některé z těchto přidělení (4k na připojení) musely Kestrel při čekání na SslStream dokončení čtení držet do ArrayPool<T> vyrovnávací paměti. Vzhledem k tomu, že tato připojení byla nečinná, žádná čtení se nedokončila a nevrátila jejich vyrovnávací paměti ArrayPool, a vynutilo ArrayPool přidělení více paměti. Zbývající přidělení byla sama o SslStream sobě: 4k vyrovnávací paměť pro handshake tls a 32k vyrovnávací paměť pro normální čtení. Když uživatel v .NET 6 provede nulové čtení SslStream bajtů a nemá k dispozici žádná data, SslStream interně provede čtení s nulovým bajtem u podkladového zabaleného datového proudu. V nejlepším případě (nečinné připojení) mají tyto změny za následek úsporu 40 kB na připojení a zároveň umožní příjemci (Kestrel) být upozorněni, když jsou data k dispozici, aniž by se zdržovala v nevyužitých vyrovnávacích pamětích.

Nulové bajtové čtení pomocí PipeReader

Při podporovaných SslStreamčtení bez vyrovnávací paměti byla přidána možnost provádět nulové bajty čtení do StreamPipeReader, interní typ, který se přizpůsobí Stream .PipeReader In Kestrel,StreamPipeReader slouží k přizpůsobení podkladu SslStream PipeReaderdo . Proto bylo nutné zveřejnit tyto nulové bajtové sémantiky čtení na PipeReader.

Pomocí PipeReader následujícího rozhraní API teď můžete vytvořit funkci podporující nulové bajty čtení v jakémkoli podkladovém objektu Stream , který podporuje sémantika nulového bajtu (např. SslStream, NetworkStreamatd.):

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

Vyjměte desky z SlabMemoryPool

Pro snížení fragmentace haldy se použila technika, Kestrel při které přidělila desky paměti 128 kB jako součást fondu paměti. Desky byly dále rozděleny do 4kB bloků, které byly použity Kestrel interně. Desky musely být větší než 85 kB, aby se vynutily přidělení velké haldy objektu, aby se pokusily a zabránily přemístění tohoto pole GC. Při zavedení nové generace GC však připnutá halda objektu (POH) už nemá smysl přidělovat bloky na desce. Kestrel nyní přímo přiděluje bloky na POH, což snižuje složitost při správě fondu paměti. Tato změna by měla usnadnit provádění budoucích vylepšení, jako je jednodušší zmenšit fond paměti používaný Kestrel.

Podpora IAsyncDisposable

IAsyncDisposable je nyní k dispozici pro kontrolery, Razor stránky a součásti zobrazení. Asynchronní verze byly přidány do příslušných rozhraní v továrnách a aktivátorech:

  • Nové metody nabízejí výchozí implementaci rozhraní, která deleguje na synchronní verzi a volání Dispose.
  • Implementace přepíší výchozí implementaci a zpracovávají implementace.IAsyncDisposable
  • Implementace upřednostňují IAsyncDisposable IDisposable při implementaci obou rozhraní.
  • Extendery musí přepsat nové metody zahrnuté pro podporu IAsyncDisposable instancí.

IAsyncDisposable je přínosná při práci s:

  • Asynchronní enumerátory, například v asynchronních datových proudech.
  • Nespravované prostředky, které mají uvolnit vstupně-výstupní operace náročné na prostředky.

Při implementaci tohoto rozhraní použijte metodu DisposeAsync k uvolnění prostředků.

Zvažte kontroler, který vytváří a používá Utf8JsonWriter. Utf8JsonWriterIAsyncDisposable je prostředek:

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());
    }

IAsyncDisposable musí implementovat DisposeAsync:

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

    _jsonWriter = null;
}

Port Vcpkg pro SignalR klienta C++

Vcpkg je správce balíčků příkazového řádku pro různé platformy pro knihovny C a C++. Nedávno jsme přidali port pro vcpkg přidání CMake nativní podpory pro SignalR klienta C++. vcpkg funguje také s nástrojem MSBuild.

Klienta SignalR lze přidat do projektu CMake s následujícím fragmentem kódu, když je soubor vcpkg součástí souboru toolchain:

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

S předchozím fragmentem kódu SignalR je klient C++ připravený k použití #include a použití v projektu bez jakékoli další konfigurace. Úplný příklad aplikace C++, která využívá SignalR klienta C++, najdete v úložišti halter73/SignalR-Client-Cpp-Sample .

Blazor

Změny šablony projektu

U aplikací bylo provedeno Blazor několik změn šablony projektu, včetně použití Pages/_Layout.cshtml souboru pro obsah rozložení, který se v souboru zobrazil pro _Host.cshtml dřívější Blazor Server aplikace. Prostudujte si změny vytvořením aplikace ze šablony projektu 6.0 nebo přístupem ke zdroji referencí ASP.NET Core pro šablony projektu:

Blazor WebAssembly Podpora nativních závislostí

Blazor WebAssembly Aplikace můžou používat nativní závislosti vytvořené ke spuštění na WebAssembly. Další informace najdete v tématu ASP.NET nativní závislosti coreBlazor WebAssembly.

Opětovné propojení webAssembly s předstihem (AOT) a opětovné propojení modulu runtime

Blazor WebAssembly podporuje kompilaci AOT (head-of-time), kde můžete kód .NET zkompilovat přímo do WebAssembly. Kompilace AOT vede ke zlepšení výkonu za běhu na úkor větší velikosti aplikace. Opětovným propojením modulu runtime .NET WebAssembly se oříznou nepoužitý kód modulu runtime a tím se zvýší rychlost stahování. Další informace najdete v tématu Kompilace AOT (Head-of-Time) kompilace a opětovné propojení modulu runtime.

Trvalý předsekenderovaný stav

Blazor podporuje zachování stavu na předsekané stránce, aby se stav při úplném načtení aplikace nemusel znovu vytvářet. Další informace najdete v tématu Integrace komponent ASP.NET Core Razor s MVC nebo Razor Pages.

Hranice chyb

Hranice chyb poskytují pohodlný přístup pro zpracování výjimek na úrovni uživatelského rozhraní. Další informace najdete v tématu Zpracování chyb v aplikacích ASP.NET CoreBlazor.

Podpora SVG

Element <foreignObject> je podporován pro zobrazení libovolného HTML v rámci SVG. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Blazor Server podpora přenosu bajtového pole v JS rámci spolupráce

Blazor podporuje optimalizovanou bajtů maticovou JS interoperabilitu, která zabraňuje kódování a dekódování bajtových polí do Base64. Další informace naleznete v následujících zdrojích:

Vylepšení řetězce dotazu

Vylepšili jsme podporu pro práci s řetězci dotazů. Další informace najdete v tématu ASP.NET Blazor Základní směrování a navigace.

Vazba pro výběr více

Vazba podporuje výběr více možností s <input> prvky. Další informace naleznete v následujících zdrojích:

Head (<head>) content control

Razor komponenty mohou upravit obsah elementu HTML <head> stránky, včetně nastavení názvu stránky (<title> element) a úpravy metadat (<meta> elementů). Další informace najdete v tématu Řízení <head> obsahu v aplikacích ASP.NET CoreBlazor.

Generování komponent Angular a React

Vygenerujte komponenty JavaScriptu specifické pro architekturu z Razor komponent pro webové architektury, jako je Angular nebo React. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Vykreslování komponent pomocí JavaScriptu

Dynamicky vykreslujte Razor komponenty z JavaScriptu pro stávající aplikace JavaScriptu. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Vlastní prvky

Experimentální podpora je k dispozici pro vytváření vlastních prvků, které používají standardní rozhraní HTML. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Odvození obecných typů součástí z nadřazených komponent

Nadřazená komponenta může kaskádovat parametr typu podle názvu na potomky pomocí nového [CascadingTypeParameter] atributu. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Dynamicky vykreslené komponenty

K vykreslení komponent podle typu použijte novou integrovanou DynamicComponent komponentu. Další informace najdete v tématu Dynamicky vykreslené komponenty ASP.NET CoreRazor.

Vylepšená Blazor přístupnost

Pomocí nové FocusOnNavigate komponenty nastavte fokus uživatelského rozhraní na prvek založený na selektoru CSS po přechodu z jedné stránky na jinou. Další informace najdete v tématu ASP.NET Blazor Základní směrování a navigace.

Podpora argumentů vlastních událostí

Blazor podporuje vlastní argumenty událostí, které umožňují předat libovolné data obslužným rutinům událostí .NET s vlastními událostmi. Další informace najdete v tématu ASP.NET Zpracování událostí CoreBlazor.

Povinné parametry

Použijte nový [EditorRequired] atribut k určení požadovaného parametru komponenty. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Umístění souborů JavaScriptu se stránkami, zobrazeními a komponentami

Uspořádejte soubory JavaScriptu pro stránky, zobrazení a Razor komponenty jako pohodlný způsob, jak uspořádat skripty v aplikaci. Další informace najdete v tématu ASP.NET Interoperabilita Core Blazor JavaScriptu (JSinteroperabilita).

Inicializátory JavaScriptu

Inicializátory JavaScriptu spouští logiku před načtením Blazor a po načtení aplikace. Další informace najdete v tématu ASP.NET Interoperabilita Core Blazor JavaScriptu (JSinteroperabilita).

Streamování interoperability JavaScriptu

Blazor teď podporuje streamování dat přímo mezi .NET a JavaScriptem. Další informace naleznete v následujících zdrojích:

Omezení obecného typu

Parametry obecného typu jsou nyní podporovány. Další informace najdete v tématu ASP.NET základní Razor komponenty.

Rozložení nasazení WebAssembly

Pomocí rozložení nasazení můžete povolit Blazor WebAssembly stahování aplikací v prostředích s omezeným zabezpečením. Další informace najdete v tématu Rozložení nasazení pro aplikace hostované Blazor WebAssemblyASP.NET Core.

Nové Blazor články

Kromě Blazor funkcí popsaných v předchozích částech jsou nové Blazor články k dispozici na následujících tématech:

Vytváření Blazor Hybrid aplikací pomocí .NET MAUIWPF a model Windows Forms

Umožňuje Blazor Hybrid kombinovat desktopové a mobilní nativní klientské architektury s .NET a Blazor:

  • .NET Multi-platform App UI (.NET MAUI) je multiplatformní architektura pro vytváření nativních mobilních a desktopových aplikací pomocí C# a XAML.
  • Blazor HybridAplikace je možné sestavit pomocí windows Presentation Foundation (WPF) a model Windows Forms architektur.

Důležité

Blazor Hybrid je ve verzi Preview a nemělo by se v produkčních aplikacích používat až do konečné verze.

Další informace naleznete v následujících zdrojích:

Kestrel

PROTOKOL HTTP/3 je aktuálně v konceptu, a proto se může změnit. Podpora PROTOKOLU HTTP/3 v ASP.NET Core není vydána, jedná se o funkci Preview, která je součástí .NET 6.

Kestrel nyní podporuje PROTOKOL HTTP/3. Další informace najdete v tématu Použití protokolu HTTP/3 s webovým serverem ASP.NET Core Kestrel a podporou položky blogu HTTP/3 v rozhraní .NET 6.

Nové Kestrel kategorie protokolování pro vybrané protokolování

Před touto změnou bylo povolení podrobného protokolování Kestrel pro zakázatelně nákladné, protože všechny sdílené Kestrel Microsoft.AspNetCore.Server.Kestrel název kategorie protokolování. Microsoft.AspNetCore.Server.Kestrel je stále k dispozici, ale následující nové podkategorie umožňují větší kontrolu nad protokolováním:

  • Microsoft.AspNetCore.Server.Kestrel(aktuální kategorie): ApplicationError, ConnectionHeadResponseBodyWrite, , RequestBodyStartApplicationNeverCompleted, RequestBodyDoneRequestBodyNotEntirelyRead, RequestBodyDrainTimedOut, , ResponseMinimumDataRateNotSatisfied, InvalidResponseHeaderRemovedHeartbeatSlow
  • Microsoft.AspNetCore.Server.Kestrel.BadRequests: ConnectionBadRequest, RequestProcessingError, RequestBodyMinimumDataRateNotSatisfied.
  • Microsoft.AspNetCore.Server.Kestrel.Connections: ConnectionAccepted, ConnectionStart, ConnectionStop, , ConnectionPause, , , ConnectionDisconnectApplicationAbortedConnectionNotAllConnectionsAbortedNotAllConnectionsClosedGracefullyConnectionRejectedConnectionResumeConnectionKeepAlive
  • Microsoft.AspNetCore.Server.Kestrel.Http2: Http2ConnectionError, Http2ConnectionClosing, , Http2ConnectionClosed, Http2StreamError, Http2StreamResetAbort, HPackDecodingError, Http2FrameReceivedHPackEncodingError, Http2FrameSending, . Http2MaxConcurrentStreamsReached
  • Microsoft.AspNetCore.Server.Kestrel.Http3: Http3ConnectionError, Http3ConnectionClosing, Http3ConnectionClosed, , Http3StreamAbort, Http3FrameReceived, Http3FrameSending.

Stávající pravidla nadále fungují, ale teď můžete být selektivnější, která pravidla povolíte. Například nároky na pozorovatelnost při povolování Debug protokolování pouze chybných požadavků jsou výrazně sníženy a lze je povolit pomocí následující konfigurace:

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

Filtrování protokolů používá pravidla s nejdelší odpovídající předponou kategorie. Další informace naleznete v tématu Jak se používají pravidla filtrování.

Generování KestrelServerOptions prostřednictvím události EventSource

KestrelEventSource vygeneruje novou událost obsahující JSON serializovanýKestrelServerOptions, pokud je povolena s podrobnostmi EventLevel.LogAlways. Tato událost usnadňuje zdůvodnění chování serveru při analýze shromážděných trasování. Příkladem datové části události je následující JSON:

{
  "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"
    }
  ]
}

Nová událost DiagnosticSource pro odmítnuté požadavky HTTP

Kestrel nyní generuje novou DiagnosticSource událost pro požadavky HTTP odmítnuté na vrstvě serveru. Před touto změnou nebylo žádný způsob, jak sledovat tyto odmítnuté žádosti. Nová DiagnosticSource událost Microsoft.AspNetCore.Server.Kestrel.BadRequest obsahuje IBadRequestExceptionFeature událost, kterou lze použít k introspekci důvodu zamítnutí požadavku.

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();
}

Další informace naleznete v tématu Protokolování a diagnostika v Kestrelnástroji .

Vytvoření connectionContextu z accept socketu

Nové SocketConnectionContextFactory umožňuje vytvořit z přijatého soketu ConnectionContext . Díky tomu můžete vytvořit vlastní soket, IConnectionListenerFactory aniž by došlo ke ztrátě veškeré práce na výkonu a sdružování probíhajících v SocketConnectionu.

Podívejte se na tento příklad vlastního IConnectionListenerFactory , který ukazuje, jak použít tento SocketConnectionContextFactory.

Kestrel je výchozí spouštěcí profil pro Visual Studio.

Výchozí spouštěcí profil pro všechny nové webové projekty dotnet je Kestrel. Spouštění Kestrel je výrazně rychlejší a má za následek rychlejší odezvu při vývoji aplikací.

Služba IIS Express je stále dostupná jako spouštěcí profil pro scénáře, jako je ověřování systému Windows nebo sdílení portů.

Porty localhost pro Kestrel jsou náhodné

Další informace najdete v části Šablony vygenerované porty Kestrel v tomto dokumentu.

Ověřování a autorizace

Ověřovací servery

Rozhraní .NET 3 až .NET 5 jako součást naší šablony používalo IdentityServer4 k podpoře vydávání tokenů JWT pro SPA a Blazor aplikace. Šablony teď používají Duende Identity Server.

Pokud rozšiřujete identity modely a aktualizujete existující projekty, aktualizujte obory názvů v kódu IdentityServer4.IdentityServer Duende.IdentityServer a postupujte podle pokynů k migraci.

Licenční model pro Duende Identity Server se změnil na reciproční licenci, která může vyžadovat licenční poplatky při komerčním použití v produkčním prostředí. Další podrobnosti najdete na stránce s licencí Duende.

Zpožděné vyjednávání klientských certifikátů

Vývojáři se teď můžou přihlásit k používání zpožděných vyjednávání klientských certifikátů zadáním ClientCertificateMode.DelayCertificate na kartě HttpsConnectionAdapterOptions. To funguje jenom s připojeními HTTP/1.1, protože HTTP/2 zakazuje zpožděné opakované vyjednávání certifikátů. Volající tohoto rozhraní API musí před vyžádáním klientského certifikátu ukládat text požadavku do vyrovnávací paměti:

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 Posuvné vypršení platnosti ověřování lze nyní přizpůsobit nebo potlačit pomocí nové OnCheckSlidingExpiration. Tuto událost může například používat jednostráňová aplikace, která musí pravidelně testovat příkazem ping na server, aniž by to mělo vliv na relaci ověřování.

Různé

Opětovné načítání za provozu

Rychlé aktualizace uživatelského rozhraní a kódu pro spuštěné aplikace, aniž by se ztratil stav aplikace, aby bylo rychlejší a produktivnější vývojářské prostředí pomocí Opětovné načítání za provozu. Další informace najdete v tématu podpora Opětovné načítání za provozu platformy .NET pro ASP.NET Core a aktualizace v .NET Opětovné načítání za provozu průběhu a zvýraznění sady Visual Studio 2022.

Vylepšené jednostránkové šablony aplikací (SPA)

Šablony projektů ASP.NET Core byly aktualizovány pro Angular a React tak, aby používaly vylepšený vzor pro jednostrákové aplikace, které jsou flexibilnější a přesněji v souladu s běžnými vzory pro moderní vývoj front-endových webů.

Dříve šablona ASP.NET Core pro Angular a React používala během vývoje specializovaný middleware ke spuštění vývojového serveru pro front-endovou architekturu a následnému proxy požadavku z ASP.NET Core na vývojový server. Logika pro spuštění front-endového vývojového serveru byla specifická pro rozhraní příkazového řádku pro odpovídající front-endovou architekturu. Podpora dalších front-endových architektur pomocí tohoto modelu znamená přidání další logiky do ASP.NET Core.

Aktualizované šablony ASP.NET Core pro Angular a React v .NET 6 překlopí toto uspořádání a využívají výhod integrované podpory proxy na vývojových serverech většiny moderních front-endových architektur. Když se spustí aplikace ASP.NET Core, spustí se front-endový vývojový server stejně jako předtím, ale vývojový server je nakonfigurovaný tak, aby proxy požadavky na back-endový proces ASP.NET Core. Veškerá konfigurace specifická pro front-end pro nastavení proxy serveru je součástí aplikace, nikoli ASP.NET Core. Nastavení ASP.NET základních projektů pro práci s jinými front-endovými architekturami je teď jednoduché: nastavte front-endový vývojový server pro zvolenou architekturu tak, aby proxy do back-endu ASP.NET Core používal vzor vytvořený v šablonách Angular a React.

Spouštěcí kód aplikace ASP.NET Core už nepotřebuje logiku specifickou pro jednu stránku. Logika pro spuštění front-endového vývojového serveru během vývoje se do aplikace za běhu vloží pomocí nového balíčku Microsoft.AspNetCore.SpaProxy . Náhradní směrování se zpracovává pomocí směrování koncového bodu místo middlewaru specifického pro SPA.

Šablony, které tento vzor následují, se dají v sadě Visual Studio spustit jako jeden projekt nebo použít dotnet run z příkazového řádku. Po publikování aplikace se front-endový kód ve složce ClientApp sestaví a shromáždí jako předtím do webového kořenového adresáře aplikace hostitele ASP.NET Core a bude sloužit jako statické soubory. Skripty zahrnuté v šabloně konfigurují front-endový vývojový server tak, aby používal PROTOKOL HTTPS pomocí vývojového certifikátu ASP.NET Core.

Koncept podpory HTTP/3 v .NET 6

PROTOKOL HTTP/3 je aktuálně v konceptu, a proto se může změnit. Podpora PROTOKOLU HTTP/3 v ASP.NET Core není vydána, jedná se o funkci Preview, která je součástí .NET 6.

Podívejte se na podporu http/3 v blogovém příspěvku v .NET 6.

Poznámky typu odkazu s možnou hodnotou null

U částí zdrojového kódu ASP.NET Core 6.0 byly použity poznámky s nulovou dostupností .

Díky použití nové funkce s možnou hodnotou Null v jazyce C# 8 může ASP.NET Core poskytovat dodatečnou bezpečnost v době kompilace při zpracování referenčních typů. Například ochrana před null výjimkami odkazu. U projektů, které se přihlásili k používání poznámek s možnou hodnotou null, se můžou zobrazit nová upozornění na dobu sestavení z rozhraní ASP.NET Core API.

Chcete-li povolit odkazové typy s možnou hodnotou null, přidejte do souborů projektu následující vlastnost:

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

Další informace naleznete v tématu Odkazové typy s možnou hodnotou Null.

Analýza zdrojového kódu

Bylo přidáno několik analyzátorů platformy kompilátoru .NET, které kontrolují kód aplikace pro problémy, jako je nesprávná konfigurace middlewaru nebo pořadí, konflikty směrování atd. Další informace najdete v tématu Analýza kódu v aplikacích ASP.NET Core.

Vylepšení šablony webové aplikace

Šablony webové aplikace:

  • Použijte nový minimální model hostování.
  • Výrazně snižuje počet souborů a řádků kódu potřebných k vytvoření aplikace. Například prázdná webová aplikace ASP.NET Core vytvoří jeden soubor C# se čtyřmi řádky kódu a je kompletní aplikací.
  • Sjednocuje a Program.cs sjednocuje Startup.cs jeden Program.cs soubor.
  • Pomocí příkazů nejvyšší úrovně minimalizujete kód potřebný pro aplikaci.
  • Používá globální using direktivy k odstranění nebo minimalizaci počtu požadovaných using řádků příkazů .

Vygenerované porty šablony pro Kestrel

Náhodné porty jsou přiřazeny během vytváření projektu pro použití webovým Kestrel serverem. Náhodné porty pomáhají minimalizovat konflikt portů při spuštění více projektů na stejném počítači.

Při vytvoření projektu se v generovaném Properties/launchSettings.json souboru zadává náhodný port HTTP mezi 5000–5300 a náhodným portem HTTPS mezi 7000–7300. Porty lze v Properties/launchSettings.json souboru změnit. Pokud není zadaný žádný port, Kestrel použije se výchozí hodnota portů HTTP 5000 a HTTPS 5001. Další informace najdete v tématu Konfigurace koncových bodů pro webový server ASP.NET CoreKestrel.

Nové výchozí nastavení protokolování

V obou appsettings.json appsettings.Development.jsonpřípadech byly provedeny následující změny:

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

Změna z "Microsoft": "Warning" na výsledek protokolování všech informačních zpráv z Microsoft oboru názvů s výjimkou Microsoft.AspNetCore."Microsoft.AspNetCore": "Warning" Teď se například Microsoft.EntityFrameworkCore protokoluje na informační úrovni.

Stránka výjimky pro vývojáře – Middleware se přidal automaticky

Ve vývojovém prostředí se DeveloperExceptionPageMiddleware ve výchozím nastavení přidá. Už není nutné do aplikací webového uživatelského rozhraní přidat následující kód:

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

Podpora hlaviček požadavků kódovaných v latince 1 v HttpSysServer

HttpSysServer nyní podporuje dekódování hlaviček požadavků, které jsou Latin1 kódovány nastavením UseLatin1RequestHeaders vlastnosti na HttpSysOptions true:

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

var app = builder.Build();

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

app.Run();

Protokoly základního modulu ASP.NET zahrnují časová razítka a PID.

Rozšířené diagnostické protokoly ASP.NET Core Module (ANCM) pro SLUŽBU IIS (ANCM) zahrnují časová razítka a PID procesu, který protokoly generuje. Protokolování časových razítek a PID usnadňuje diagnostiku problémů s překrývajícími se restartováními procesů ve službě IIS při spuštění více pracovních procesů služby IIS.

Výsledné protokoly se teď podobají ukázkovém výstupu níže:

[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: ''

Konfigurovatelná nekonsumovaná velikost příchozí vyrovnávací paměti pro službu IIS

Server IIS dříve vytáčil do vyrovnávací paměti pouze 64 KiB nekonsumovaných subjektů požadavků. Vyrovnávací paměť 64 KiB způsobila omezení čtení na tuto maximální velikost, což má vliv na výkon u velkých příchozích těl, jako jsou nahrávání. V .NET 6 se výchozí velikost vyrovnávací paměti změní z 64 KiB na 1 MiB, což by mělo zlepšit propustnost pro velké nahrávání. V našich testech trvá nahrávání MiB 700, které trvalo 9 sekund, teď trvá jenom 2,5 sekundy.

Nevýhodou větší velikosti vyrovnávací paměti je zvýšená spotřeba paměti pro jednotlivé požadavky, když aplikace z textu požadavku rychle nečte. Kromě změny výchozí velikosti vyrovnávací paměti je velikost vyrovnávací paměti konfigurovatelná a umožňuje aplikacím konfigurovat velikost vyrovnávací paměti na základě zatížení.

Pomocné rutiny pro zobrazení značek komponent

Zvažte součást zobrazení s volitelným parametrem, jak je znázorněno v následujícím kódu:

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

S ASP.NET Core 6 se dá pomocná rutina značek vyvolat, aniž by bylo nutné zadat hodnotu parametru showSomething :

<vc:my />

Šablona Angular byla aktualizována na Angular 12

Šablona ASP.NET Core 6.0 pro Angular teď používá Angular 12.

Šablona React byla aktualizována na React 17.

Konfigurovatelná prahová hodnota vyrovnávací paměti před zápisem na disk v Json.NET výstupním formátovacím modulu

Poznámka: Doporučujeme použít System.Text.Json výstupní formátovací modul s výjimkou případů, kdy Newtonsoft.Json je serializátor vyžadován z důvodů kompatibility. Serializátor System.Text.Json je plně async funkční a efektivně funguje pro větší datové části.

Výstupní Newtonsoft.Json formátovací modul ve výchozím nastavení vyrovnávací paměti před uložením do vyrovnávací paměti do vyrovnávací paměti až 32 KiB. Tím se zabráníte provádění synchronních vstupně-výstupních operací, což může vést k dalším vedlejším účinkům, jako jsou hladovění vláken a zablokování aplikací. Pokud je však odpověď větší než 32 KiB, dojde k značnému počtu vstupně-výstupních operací disku. Prahová hodnota paměti je nyní konfigurovatelná prostřednictvím MvcNewtonsoftJsonOptions.OutputFormatterMemoryBufferThreshold vlastnost před uložením do vyrovnávací paměti na disk:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

Další informace najdete v této žádosti o přijetí změn na GitHubu a v souboru NewtonsoftJsonOutputFormatterTest.cs .

Rychlejší získání a nastavení pro hlavičky HTTP

Byla přidána nová rozhraní API, která zpřístupňují všechny společné hlavičky, které jsou k dispozici Microsoft.Net.Http.Headers.HeaderNames jako vlastnosti ve IHeaderDictionary výsledku, což usnadňuje použití rozhraní API. Například vložený middleware v následujícím kódu získá a nastaví hlavičky požadavku i odpovědi pomocí nových rozhraní 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();

U implementovaných hlaviček jsou přístupové objekty get a set implementovány tak, že přejdete přímo do pole a vynecháte vyhledávání. U neimplementovaných hlaviček můžou přístupové objekty obejít počáteční vyhledávání proti implementovaným záhlavím a přímo provést Dictionary<string, StringValues> vyhledávání. Vyhnete se výsledkům vyhledávání rychlejší přístup pro oba scénáře.

Asynchronní streamování

ASP.NET Core teď podporuje asynchronní streamování z akcí kontroleru a odpovědí z formátovače JSON. Vrácení akce IAsyncEnumerable z akce už neumischuje obsah odpovědi do paměti před odesláním. Ukládání do vyrovnávací paměti pomáhá snížit využití paměti při vracení velkých datových sad, které je možné asynchronně vytvořit výčet.

Všimněte si, že Entity Framework Core poskytuje implementace IAsyncEnumerable pro dotazování databáze. Vylepšená podpora IAsyncEnumerable pro ASP.NET Core v .NET 6 umožňuje efektivnější použití EF Core s ASP.NET Core. Například následující kód už před odesláním odpovědi neuchová data produktu do paměti:

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

Pokud však používáte opožděné načítání EF Core, může toto nové chování vést k chybám kvůli souběžnému provádění dotazů při vytváření výčtu dat. Aplikace se můžou vrátit k předchozímu chování uložením dat do vyrovnávací paměti:

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

Další podrobnosti o této změně chování najdete v souvisejícím oznámení .

Middleware protokolování HTTP

Protokolování HTTP je nový integrovaný middleware, který protokoluje informace o požadavcích HTTP a odpovědích HTTP, včetně hlaviček a celého textu:

var builder = WebApplication.CreateBuilder(args);

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

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

app.Run();

Přechod na / předchozí informace o protokolech kódu podobný následujícímu výstupu:

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

Předchozí výstup byl povolen s následujícím appsettings.Development.json souborem:

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

Protokolování HTTP poskytuje protokoly obsahující:

  • Informace o požadavku HTTP
  • Obecné vlastnosti
  • Hlavičky
  • Text
  • Informace o odpovědi HTTP

Pokud chcete nakonfigurovat middleware protokolování HTTP, zadejte 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

Funkce IConnectionSocketFeature požadavku poskytuje přístup k podkladovému soketu accept přidruženému k aktuálnímu požadavku. Lze k němu přistupovat prostřednictvím FeatureCollection on HttpContext.

Například následující aplikace nastaví LingerState vlastnost na přijatém soketu:

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();

Omezení obecného typu v Razor

Při definování parametrů obecného typu v Razor použití @typeparam direktivy je nyní možné zadat omezení obecného typu pomocí standardní syntaxe jazyka C#:

Menší SignalRskripty , Blazor Servera MessagePack

Balíček SignalRMessagePack a Blazor Server skripty jsou teď výrazně menší, což umožňuje menší stahování, menší analýzu a kompilaci JavaScriptu v prohlížeči a rychlejší spuštění. Snížení velikosti:

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

Menší skripty jsou výsledkem příspěvku komunity Od Ben Adams. Další informace o podrobnostech o zmenšení velikosti najdete v žádosti o přijetí změn Na GitHubu od Bena.

Povolení relací profilace Redis

Příspěvek komunity od Gabriel Lucaci umožňuje profilaci relace Redis s Microsoft.Extensions.Caching.StackExchangeRedis:

using StackExchange.Redis.Profiling;

var builder = WebApplication.CreateBuilder(args);

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

Další informace naleznete v tématu StackExchange.Redis Profiling.

Stínová kopie ve službě IIS

Do modulu ASP.NET Core (ANCM) pro SLUŽBU IIS byla přidána experimentální funkce, která přidává podporu pro sestavení aplikace stínové kopírování. V současné době .NET zamkne binární soubory aplikací při spuštění ve Windows, takže při spuštění aplikace není možné binární soubory nahradit. I když naše doporučení zůstává používat offline soubor aplikace, zjistili jsme, že existují určité scénáře (například nasazení FTP), kdy to není možné provést.

V takových scénářích povolte stínové kopírování přizpůsobením nastavení obslužné rutiny modulu ASP.NET Core. Ve většině případů ASP.NET aplikace Core nemají web.config kontrolu nad správou zdrojového kódu, kterou můžete upravit. V ASP.NET Core web.config se obvykle generuje sadou SDK. K zahájení práce můžete použít následující ukázku 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>

Stínová kopie ve službě IIS je experimentální funkce, která není zaručená, že je součástí ASP.NET Core. V tomto problému s GitHubem nám napište svůj názor na stínové kopírování služby IIS.

Další materiály