Sdílet prostřednictvím

Novinky v ASP.NET Core v .NET 8

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

Blazor

Plnohodnotné webové uživatelské rozhraní

Ve verzi .NET 8 Blazor je plnohodnotná architektura webového uživatelského rozhraní pro vývoj aplikací, které vykreslují obsah na úrovni komponenty nebo stránky:

  • Vykreslování statického serveru (také nazývané jako statické vykreslování na straně serveru, statické SSR) pro generování statického HTML na serveru.
  • Interaktivní vykreslování na serveru (označované také jako interaktivní vykreslování na straně serveru, interaktivní SSR) k vytváření interaktivních komponent s předrenderingem na serveru.
  • Interaktivní vykreslování WebAssembly (označované také jako vykreslování na straně klienta, CSR, což se vždy předpokládá jako interaktivní) pro generování interaktivních komponent na klientovi s předběžným vykreslováním na serveru.
  • Interaktivní automatické vykreslování pro počáteční použití runtime ASP.NET Core na straně serveru pro vykreslování obsahu a zajištění interaktivity. Běhové prostředí .NET WebAssembly na klientovi se používá k dalšímu vykreslování a interaktivitě po stažení svazku Blazor a aktivaci běhového prostředí WebAssembly. Interaktivní automatické vykreslování obvykle poskytuje nejrychlejší zážitek při spuštění aplikace.

Interaktivní režimy vykreslování také ve výchozím nastavení předkreslují obsah.

Další informace najdete v následujících článcích:

Příklady v celé Blazor dokumentaci byly aktualizovány pro použití ve Blazor Web Appch. Blazor Server příklady zůstávají v obsahové verzi pro .NET 7 nebo starší.

Nový článek o knihovnách tříd se statickým vykreslováním na straně serveru (statická SSR)

Přidali jsme nový článek, který popisuje autorství knihovny komponent v Razor knihovnách tříd (RCLS) se statickým vykreslováním na straně serveru (static SSR).

Další informace najdete v tématu ASP.NET Core Razor knihovny tříd (RCLs) se statickým vykreslováním na straně serveru (statické SSR).

Nový článek o problémech s ukládáním do mezipaměti HTTP

Přidali jsme nový článek, který popisuje některé běžné problémy s ukládáním do mezipaměti HTTP, ke kterým může dojít při upgradu Blazor aplikací napříč hlavními verzemi a o řešení problémů s ukládáním do mezipaměti HTTP.

Další informace najdete v tématu Zabránění problémům s ukládáním do mezipaměti HTTP při upgradu aplikací ASP.NET CoreBlazor.

Nová Blazor Web App šablona

Zavedli jsme novou Blazor šablonu projektu: Blazor Web App šablonu. Nová šablona poskytuje jediný výchozí bod pro použití Blazor komponent k sestavení libovolného stylu webového uživatelského rozhraní. Šablona kombinuje silné stránky stávajících Blazor Server a Blazor WebAssembly hostitelských modelů s novými Blazor funkcemi přidanými v .NET 8: statické vykreslování na straně serveru (statické SSR), vykreslování streamování, vylepšená navigace a zpracování formulářů a možnost přidat interaktivitu pomocí jednotlivých Blazor ServerBlazor WebAssembly komponent.

V rámci sjednocení různých Blazor modelů hostování do jednoho modelu v .NET 8 také slučujeme počet Blazor šablon projektů. Odstranili jsme šablonu Blazor Server a z šablony Blazor WebAssembly byla odstraněna možnost ASP.NET Core Hosted. Obě tyto scénáře jsou reprezentovány možnostmi při použití Blazor Web App šablony.

Note

Stávající Blazor Server a Blazor WebAssembly aplikace zůstávají podporované v .NET 8. Volitelně je možné tyto aplikace aktualizovat tak, aby používaly nové funkce webového uživatelského rozhraní Blazor s plnou sadou.

Další informace o nové Blazor Web App šabloně najdete v následujících článcích:

Nové inicializátory JS pro Blazor Web Appy

Pro aplikace Blazor Server, Blazor WebAssembly a Blazor Hybrid:

  • beforeStart se používá pro úlohy, jako je přizpůsobení procesu načítání, úrovně protokolování a dalších možností.
  • afterStarted se používá pro úlohy, jako je registrace posluchačů událostí Blazor a vlastní typy událostí.

Předchozí starší JS inicializátory nejsou ve výchozím nastavení vyvolány v Blazor Web App. Pro Blazor Web Apps se používá nová sada JS inicializátorů: beforeWebStart, afterWebStarted, beforeServerStart, afterServerStarted, , beforeWebAssemblyStart, a afterWebAssemblyStarted.

Další informace najdete v tématu ASP.NET Core Blazor startup.

Rozdělení pokynů k předběžnému vykreslování a integraci

V případě předchozích verzí .NET jsme se zabývali předběžnou úpravou a integrací v jednom článku. Abychom zjednodušili a zaměřili naše pokrytí, rozdělili jsme témata do následujících nových článků, které byly aktualizovány pro .NET 8:

Zachovat stav komponenty v Blazor Web App

Stav komponenty můžete zachovat a číst v Blazor Web App pomocí existující služby PersistentComponentState. To je užitečné pro zachování stavu součásti během předrenderingu.

Blazor Web Apps automaticky uchovají všechny zaregistrované stavy na úrovni aplikace vytvořené během předkreslování, což eliminuje potřebu pomocníka značky pro ukládání stavu součásti .

Zpracování formulářů a vazba modelu

Blazor komponenty teď můžou zpracovávat odeslané žádosti o formulář, včetně vazby modelu a ověřování dat žádosti. Komponenty mohou implementovat formuláře s samostatnými obslužnými rutinami formulářů pomocí standardní značky HTML <form> nebo pomocí existující EditForm komponenty.

Vazba Blazor modelu formuláře respektuje atributy kontraktu dat (například [DataMember] a [IgnoreDataMember]) pro přizpůsobení způsobu, jakým jsou data formuláře svázána s modelem.

Nová podpora antiforgery je součástí .NET 8. Nová komponenta AntiforgeryToken vykreslí token proti padělání jako skryté pole a nový atribut [RequireAntiforgeryToken] umožňuje ochranu proti padělání. Pokud kontrola proti padělání selže, vrátí se odpověď 400 (Chybný požadavek) a formulář se nezpracovává. Nové antiforgery funkce jsou ve výchozím nastavení povoleny pro formuláře založené na Editform a lze je použít ručně u standardních formulářů HTML.

Další informace najdete v přehledu formulářů ASP.NET Core.

Vylepšená navigace a zpracování formulářů

Statické vykreslování na straně serveru (statické SSR) obvykle provádí aktualizaci celé stránky pokaždé, když uživatel přejde na novou stránku nebo odešle formulář. V .NET 8 Blazor můžete vylepšit navigaci na stránce a zpracování formulářů tím, že zachytíte požadavek a místo něj provedete požadavek na načtení dat. Blazor pak zpracovává vykreslený obsah odpovědi tak, že ho vkládá do DOM prohlížeče. Vylepšená navigace a zpracování formulářů zabraňuje potřebě aktualizace celé stránky a zachovává více stavu stránky, takže stránky se načítají rychleji a plynuleji. Navigace je ve výchozím nastavení vylepšena, jakmile je Blazor skript (blazor.web.js) načten. Rozšířené zpracování formulářů lze volitelně povolit pro konkrétní formuláře.

Nové rozšířené navigační rozhraní API umožňuje aktualizovat aktuální stránku voláním NavigationManager.Refresh(bool forceLoad = false).

Další informace najdete v následujících částech Blazorčlánku Směrování :

Nový článek o statickém vykreslování s vylepšenou navigací pro JS interoperabilitu

Některé aplikace závisí na JS interoperabilitě, aby prováděly úlohy inicializace, které jsou specifické pro každou stránku. Při použití funkce rozšířené navigace Blazor se staticky vykreslenými stránkami, které provádějí úlohy inicializace vzájemné spolupráce JS, nemusí být stránkově specifické prvky JS znovu spuštěny tak, jak by se očekávalo, pokaždé, když dojde k rozšířené navigaci na dané stránce. Nový článek vysvětluje, jak tento scénář vyřešit v Blazor Web App:

ASP.NET Core Blazor JavaScript se statickým vykreslováním na straně serveru (statické SSR)

Streamované vykreslování

Nyní můžete streamovat aktualizace obsahu ve streamu odezvy při použití statického renderování na straně serveru (statické SSR) pomocí Blazor. Streamové vykreslování může zlepšit uživatelský zážitek na stránkách, které provádějí dlouhotrvající asynchronní úlohy, tím, že zobrazí obsah, jakmile je k dispozici.

Pokud například chcete vykreslit stránku, může být potřeba provést dlouhotrvající databázový dotaz nebo volání rozhraní API. Asynchronní úlohy prováděné v rámci vykreslování stránky se obvykle musí dokončit před odesláním vykreslené odpovědi, což může zpozdit načtení stránky. Vykreslování streamováním zpočátku vykreslí celou stránku se zástupným obsahem, zatímco probíhají asynchronní operace. Po dokončení asynchronních operací se aktualizovaný obsah odešle klientovi ve stejné odpovědi připojení a je vložen do modelu DOM. Výhodou tohoto přístupu je, že se hlavní rozložení aplikace vykreslí co nejrychleji a stránka se aktualizuje, jakmile bude obsah připravený.

Další informace najdete v tématu Vykreslování komponent ASP.NET Core Razor.

Vložení klíčových služeb do komponent

Blazor nyní podporuje vkládání služeb s klíči pomocí atributu [Inject] . Klíče umožňují nastavení rozsahu registrace a spotřeby služeb při použití vkládání závislostí. Pomocí nové InjectAttribute.Key vlastnosti zadejte klíč, který má služba vložit:

[Inject(Key = "my-service")]
public IMyService MyService { get; set; }

Direktiva @injectRazor nepodporuje klíčové služby pro tuto verzi, ale práce je sledována pomocí Update @inject k podpoře klíčových služeb (dotnet/razor #9286) pro budoucí verzi .NET.

Další informace najdete v tématu ASP.NET Core Blazor injektáž závislostí.

Přístup HttpContext jako kaskádový parametr

K aktuálnímu HttpContext objektu se teď dostanete jako kaskádový parametr ze statické součásti serveru:

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

HttpContext Přístup ke komponentě statického serveru může být užitečný při kontrole a úpravě hlaviček nebo jiných vlastností.

Příklad, který předává HttpContext stavové, přístupové a obnovovací tokeny komponentám, najdete v tématu ASP.NET základní serverové a Blazor Web App další scénáře zabezpečení.

Vykreslení Razor komponent mimo ASP.NET Core

Komponenty teď můžete vykreslit Razor mimo kontext HTTP dotazu. Můžete vykreslit komponenty Razor přímo do řetězce nebo streamu, a to nezávisle na hostitelském prostředí ASP.NET Core. To je vhodné pro scénáře, ve kterých chcete generovat fragmenty HTML, například pro generování e-mailu nebo statického obsahu webu.

Další informace naleznete v tématu Vykreslování Razor komponent mimo ASP.NET Core.

Podpora oddílů

Nové SectionOutlet a SectionContent komponenty v Blazor přidávají podporu pro definování výstupů pro obsah, který lze vyplnit později. Oddíly se často používají k definování zástupných symbolů v rozloženích, která jsou pak vyplněna konkrétními stránkami. Oddíly se odkazují buď jedinečným názvem, nebo pomocí jedinečného ID objektu.

Další informace najdete v částech BlazorASP.NET Core.

Podpora pro chybové stránky

Blazor Web Apps může definovat vlastní chybovou stránku pro použití s middlewarem pro zpracování výjimek ASP.NET Core. Šablona Blazor Web App projektu obsahuje výchozí chybovou stránku s podobným obsahem, který se používá v aplikacích MVC a Razor Pages. Když se chybová stránka vykreslí v reakci na požadavek z middlewaru zpracování výjimek, chybová stránka se vždy vykreslí jako součást statického serveru, i když je povolená interaktivita.

Podívejte se na komponentu Error (Components/Pages/Error.razor) serverového projektu v šabloně projektu Blazor Web App (dotnet/aspnetcore úložiště GitHub).

Note

Odkazy na referenční zdroj .NET v dokumentaci obvykle otevřou výchozí větev úložiště, která představuje aktuální vývoj další verze .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí mezi větvemi nebo značkami. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

QuickGrid

Komponenta BlazorQuickGrid už není experimentální a je nyní součástí architektury Blazor v rozhraní .NET 8.

QuickGrid je vysoce výkonná komponenta mřížky pro zobrazení dat v tabulkové podobě. QuickGrid je sestavená tak, aby byla jednoduchá a pohodlná způsob zobrazení dat, a zároveň poskytuje výkonné funkce, jako je řazení, filtrování, stránkování a virtualizace.

Další informace najdete v tématu ASP.NET Core Blazor komponentQuickGrid.

Cesta k pojmenovaným prvkům

Blazor nyní podporuje použití směrování na straně klienta k přechodu na konkrétní element HTML na stránce pomocí standardních fragmentů adresy URL. Pokud zadáte identifikátor elementu HTML pomocí standardního id atributu, správně se posune k tomuto prvku, Blazor když fragment adresy URL odpovídá identifikátoru elementu.

Další informace najdete v tématu ASP.NET Blazor Základní směrování a navigace.

Kaskádové hodnoty na kořenové úrovni

Kaskádové hodnoty kořenové úrovně lze zaregistrovat pro celou hierarchii komponent. Podporují se pojmenované kaskádové hodnoty a odběry pro oznámení o aktualizacích.

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

Virtualizace prázdného obsahu

Pomocí nového EmptyContent parametru v komponentě Virtualize zadejte obsah, pokud je komponenta načtena a Items je prázdná nebo ItemsProviderResult<T>.TotalItemCount je nula.

Další informace najdete v tématu Razor virtualizace komponent.

Zavření okruhů, pokud neexistují žádné zbývající interaktivní součásti serveru

Interaktivní součásti serveru zpracovávají události webového uživatelského rozhraní pomocí připojení v reálném čase s prohlížečem označovaným jako okruh. Nastavení obvodu a jeho přidruženého stavu proběhne při vykreslení kořenové interaktivní serverové komponenty. Okruh se zavře, pokud na stránce nejsou žádné zbývající interaktivní součásti serveru, které uvolní prostředky serveru.

Sledujte SignalR aktivitu okruhu

Nyní můžete sledovat aktivitu příchozího okruhu v serverových aplikacích pomocí nové metody CreateInboundActivityHandler na CircuitHandler. Příchozí aktivita okruhu je jakákoli aktivita odesílaná z prohlížeče na server, například události uživatelského rozhraní nebo volání pro propojení JavaScriptu s .NET.

Další informace najdete v pokynech k ASP.NET CoreBlazorSignalR.

Rychlejší výkon modulu runtime pomocí jiterpreteru

Jiterpreter je nová funkce modulu runtime v .NET 8, která umožňuje částečnou podporu kompilace JIT (Just-in-Time) při spuštění na WebAssembly, aby se dosáhlo lepšího výkonu modulu runtime.

Další informace najdete v tématu nástroje sestavení ASP.NET Core Blazor WebAssembly a předběžná kompilace (AOT).

Předběžné zpracování SIMD a ošetření výjimek (AOT)

Blazor WebAssembly ahead-of-time (AOT) kompilace teď ve výchozím nastavení využívá WebAssembly SIMD s pevnou šířkou a zpracování výjimek WebAssembly, aby se zlepšil výkon za běhu.

Další informace najdete v následujících článcích:

Balení Webcil vhodné pro web

Webcil je webové balení sestavení .NET, která odebere obsah specifický pro nativní spouštění systému Windows, aby nedocházelo k problémům při nasazování do prostředí, která blokují stahování nebo používání .dll souborů. Webcil je standardně povolen pro Blazor WebAssembly aplikace.

Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor WebAssembly.

Note

Před vydáním rozhraní .NET 8 se pokyny v rozložení nasazení pro ASP.NET Core hostované Blazor WebAssembly aplikace zabývají prostředími, která blokují stahování a spouštění knihoven DLL pomocí vícedílného sdružování. V rozhraní .NET 8 nebo novější Blazor používá k vyřešení tohoto problému formát souboru Webcil. Vícedílné sdružování pomocí experimentálního balíku NuGet popsaného v článku o rozložení nasazení WebAssembly se nepodporuje pro Blazor aplikace v .NET 8 nebo novější. Další informace najdete v tématu Vylepšení Microsoft.AspNetCore.Components.WebAssembly.MultipartBundle balíčku pro definování vlastního formátu sady prostředků (dotnet/aspnetcore #36978). Pokud chcete v aplikacích .NET 8 nebo novějších aplikacích dál používat balíček balíčku s více částmi, můžete pomocí pokynů v článku vytvořit vlastní balíček NuGet pro více částí, ale Microsoft ho nepodporuje.

Blazor WebAssembly Vylepšení ladění

Při ladění .NET na WebAssembly teď ladicí program stáhne data symbolů z umístění symbolů nakonfigurovaných v předvolbách sady Visual Studio. Tím se zlepší možnosti ladění pro aplikace, které používají balíčky NuGet.

Teď můžete ladit Blazor WebAssembly aplikace pomocí Firefoxu. Ladění aplikací Blazor WebAssembly vyžaduje konfiguraci prohlížeče pro vzdálené ladění a následné připojení k prohlížeči pomocí vývojářských nástrojů prohlížeče prostřednictvím proxy .NET WebAssembly pro ladění. Ladění Firefoxu pomocí Visual Studio není v tuto chvíli podporováno.

Další informace najdete v tématu Ladění aplikací ASP.NET CoreBlazor.

Kompatibilita zásad zabezpečení obsahu (CSP)

Blazor WebAssembly už při zadávání zásad zabezpečení obsahu (CSP) nevyžaduje povolení unsafe-eval zdroje skriptu.

Další informace naleznete v tématu Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor.

Zpracujte zachycené výjimky mimo Razor životní cyklus komponenty

Použijte ComponentBase.DispatchExceptionAsync v komponentě Razor ke zpracování výjimek vyvolaných mimo zásobník volání v rámci životního cyklu komponenty. To umožňuje kódu komponenty zacházet s výjimkami, jako by se jedná o výjimky metody životního cyklu. BlazorNásledně můžou mechanismy zpracování chyb, jako jsou hranice chyb, zpracovávat výjimky.

Pro více informací si přečtěte Blazor.

Konfigurace modulu runtime .NET WebAssembly

Modul runtime .NET WebAssembly je teď možné nakonfigurovat pro Blazor spuštění.

Další informace najdete v tématu ASP.NET Core Blazor startup.

Konfigurace časových limitů připojení v HubConnectionBuilder

Předchozí alternativní řešení pro konfiguraci časových limitů připojení rozbočovače lze nahradit formální konfigurací časových limitů pomocí tvůrce připojení rozbočovače SignalR.

Další informace najdete v následujících článcích:

Šablony projektů odstranily Open Iconic

Šablony Blazor projektů už nezávisí na Open Iconic pro ikony.

Podpora pro zrušení a zavření událostí dialogového okna

Blazor nyní podporuje události cancel a close na HTML elementu dialog.

V následujícím příkladu:

  • OnClose je volána při zavření dialogového my-dialog okna pomocí tlačítka Zavřít .
  • OnCancel je volána při zrušení dialogového okna pomocí klávesy Esc . Když se dialogové okno HTML zavře pomocí klávesy Esc, aktivují se obě události cancel a close.
<div>
    <p>Output: @message</p>

    <button onclick="document.getElementById('my-dialog').showModal()">
        Show modal dialog
    </button>

    <dialog id="my-dialog" @onclose="OnClose" @oncancel="OnCancel">
        <p>Hi there!</p>

        <form method="dialog">
            <button>Close</button>
        </form>
    </dialog>
</div>

@code {
    private string? message;

    private void OnClose(EventArgs e) => message += "onclose, ";

    private void OnCancel(EventArgs e) => message += "oncancel, ";
}

Blazor Identity UI (Uživatelské rozhraní)

Blazor podporuje generování úplného uživatelského rozhraní založeného na BlazorIdentity, při výběru možnosti ověřování pro jednotlivé účty. Můžete buď vybrat možnost pro jednotlivé účty v dialogovém okně nového projektu pro Blazor Web App ze sady Visual Studio, nebo použít sadu možností -au|--auth pro Individual v příkazovém řádku při vytváření nového projektu.

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

Zabezpečení Blazor WebAssembly pomocí ASP.NET Core Identity

V dokumentaci je nový článek a ukázková aplikace pro zabezpečení samostatné aplikace pomocí ASP.NET Core.

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

Blazor Server se směrováním Yarp

Směrování a hluboké propojení pro Blazor Server s Yarpem funguje správně v .NET 8.

Další informace najdete v tématu Migrace z ASP.NET Core v .NET 7 na .NET 8.

Více jednotek Blazor Web App pro každý serverový projekt

Pro budoucí verzi .NET je potřeba zvážit podporu více Blazor Web Appprojektů na server.

Další informace najdete v tématu Podpora více Blazor webových aplikací na jeden serverový projekt (dotnet/aspnetcore #52216).

Blazor Hybrid

Následující články popisují změny Blazor Hybrid v .NET 8:

[Parameter] Atribut se už nevyžaduje při zadání z řetězce dotazu.

Atribut [Parameter] se už nevyžaduje při zadávání parametru z řetězce dotazu:

- [Parameter]
  [SupplyParameterFromQuery]

SignalR

Nový přístup k nastavení časového limitu serveru a intervalu Udržování naživu

ServerTimeout (výchozí: 30 sekund) a KeepAliveInterval (výchozí: 15 sekund) lze nastavit přímo na HubConnectionBuilder.

Předchozí přístup pro klienty JavaScriptu

Následující příklad ukazuje přiřazení hodnot, které jsou dvojnásobné výchozí hodnoty v .NET 7 nebo starší:

var connection = new signalR.HubConnectionBuilder()
  .withUrl("/chatHub")
  .build();

connection.serverTimeoutInMilliseconds = 60000;
connection.keepAliveIntervalInMilliseconds = 30000;

Nový přístup pro klienty JavaScriptu

Následující příklad ukazuje nový přístup pro přiřazování hodnot, které jsou ve verzi .NET 8 nebo novější zdvojnásobené výchozí hodnoty:

var connection = new signalR.HubConnectionBuilder()
  .withUrl("/chatHub")
  .withServerTimeout(60000)
  .withKeepAlive(30000)
  .build();

Předchozí přístup pro JavaScriptového klienta aplikace Blazor Server

Následující příklad ukazuje přiřazení hodnot, které jsou dvojnásobné výchozí hodnoty v .NET 7 nebo starší:

Blazor.start({
  configureSignalR: function (builder) {
    let c = builder.build();
    c.serverTimeoutInMilliseconds = 60000;
    c.keepAliveIntervalInMilliseconds = 30000;
    builder.build = () => {
      return c;
    };
  }
});

Nový přístup pro klienta JavaScriptu aplikace na straně Blazor serveru

Následující příklad ukazuje nový přístup pro přiřazování hodnot, které jsou dvojnásobkem výchozích hodnot v .NET 8 nebo novější pro Blazor Web Apps a Blazor Server.

Blazor Web App:

Blazor.start({
  circuit: {
    configureSignalR: function (builder) {
      builder.withServerTimeout(60000).withKeepAliveInterval(30000);
    }
  }
});

Blazor Server:

Blazor.start({
  configureSignalR: function (builder) {
    builder.withServerTimeout(60000).withKeepAliveInterval(30000);
  }
});

Předchozí přístup pro klienty .NET

Následující příklad ukazuje přiřazení hodnot, které jsou dvojnásobné výchozí hodnoty v .NET 7 nebo starší:

var builder = new HubConnectionBuilder()
    .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
    .Build();

builder.ServerTimeout = TimeSpan.FromSeconds(60);
builder.KeepAliveInterval = TimeSpan.FromSeconds(30);

builder.On<string, string>("ReceiveMessage", (user, message) => ...

await builder.StartAsync();

Nový přístup pro klienty .NET

Následující příklad ukazuje nový přístup pro přiřazování hodnot, které jsou ve verzi .NET 8 nebo novější zdvojnásobené výchozí hodnoty:

var builder = new HubConnectionBuilder()
    .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
    .WithServerTimeout(TimeSpan.FromSeconds(60))
    .WithKeepAliveInterval(TimeSpan.FromSeconds(30))
    .Build();

builder.On<string, string>("ReceiveMessage", (user, message) => ...

await builder.StartAsync();

SignalR stavové znovupřipojení

SignalR stavové opětovné připojení snižuje vnímaný výpadek klientů, kteří mají ve svém síťovém připojení dočasné odpojení, například při přepínání síťových připojení nebo krátké dočasné ztrátě přístupu.

Stavové opětovné připojení toho dosáhne takto:

  • Dočasné ukládání dat do vyrovnávací paměti na serveru a na klientovi.
  • Potvrzení přijatých zpráv (ACK-ing) serverem i klientem
  • Když je rozpoznáno, že se připojení obnovuje, jsou znovu odesílány zprávy, které mohly být odeslány, když bylo připojení přerušeno.

Stavové opětovné připojení je k dispozici v .NET 8 nebo novějším.

Povolte stavové opětovné připojení na serveru i klientovi.

  • Aktualizujte konfiguraci koncového bodu centra serveru a povolte možnost AllowStatefulReconnects :

    app.MapHub<MyHub>("/hubName", options =>
{
    options.AllowStatefulReconnects = true;
});

    Volitelně lze maximální velikost vyrovnávací paměti v bajtech povolenou serverem nastavit globálně nebo pro konkrétní středisko pomocí volby StatefulReconnectBufferSize.

    Globální nastavení StatefulReconnectBufferSize možnosti:

    builder.AddSignalR(o => o.StatefulReconnectBufferSize = 1000);

    Sada možností StatefulReconnectBufferSize pro určitý hub:

    builder.AddSignalR().AddHubOptions<MyHub>(o => o.StatefulReconnectBufferSize = 1000);

    Možnost StatefulReconnectBufferSize je volitelná s výchozím nastavením 100 000 bajtů.

  • Aktualizujte klientský kód v JavaScriptu nebo TypeScriptu, abyste povolili možnost withStatefulReconnect.

    const builder = new signalR.HubConnectionBuilder()
  .withUrl("/hubname")
  .withStatefulReconnect({ bufferSize: 1000 });  // Optional, defaults to 100,000
const connection = builder.build();

    Možnost bufferSize je volitelná s výchozím nastavením 100 000 bajtů.

  • Aktualizujte kód klienta .NET, aby byla možnost WithStatefulReconnect povolena.

      var builder = new HubConnectionBuilder()
      .WithUrl("<hub url>")
      .WithStatefulReconnect();
  builder.Services.Configure<HubConnectionOptions>(o => o.StatefulReconnectBufferSize = 1000);
  var hubConnection = builder.Build();

    Možnost StatefulReconnectBufferSize je volitelná s výchozím nastavením 100 000 bajtů.

Další informace naleznete v tématu Konfigurace stavového opětovného připojení.

Minimální rozhraní API

Tato část popisuje nové funkce pro minimální rozhraní API. Další informace týkající se minimálních rozhraní API najdete také v části Nativní AOT .

Uživatel překrývá nastavení kultury

Počínaje rozhraním .NET 8 umožňuje vlastnost RequestLocalizationOptions.CultureInfoUseUserOverride aplikaci rozhodnout, zda použít jiná než výchozí nastavení systému Windows pro vlastnosti CultureInfoDateTimeFormat a NumberFormat. To nemá žádný vliv na Linux. To přímo odpovídá UseUserOverride.

    app.UseRequestLocalization(options =>
    {
        options.CultureInfoUseUserOverride = false;
    });

Vazba na formuláře

Explicitní vazba na hodnoty formuláře pomocí atributu [FromForm] je nyní podporována. Parametry vázané na požadavek zahrnují token proti padělání . Token antiforgery se ověří při zpracování požadavku.

Odvozené vazby na formuláře používající IFormCollectionIFormFile, a IFormFileCollection typy jsou také podporovány. OpenAPI metadata se odvozuje pro parametry formuláře, aby podporovala integraci s uživatelským rozhraním Swagger.

Další informace naleznete v tématu:

Vázání z formulářů je nyní podporováno pro:

  • Kolekce, například Seznam a Slovník
  • Složité typy, například Todo nebo Project

Další informace naleznete v tématu Připojení ke kolekcím a komplexním typům z formulářů.

Antipadělání s minimálními API rozhraními

Tato verze přidává middleware pro ověřování antiforgery tokenů, které se používají ke zmírnění útoků typu cross-site request forgery (CSRF). Zavolejte AddAntiforgery k zaregistrování těchto antiforgery služeb v DI. WebApplicationBuilder automaticky přidá middleware po registraci antiforgery služeb v kontejneru DI. Antiforgery tokeny se používají ke zmírnění útoků proti padělání požadavků mezi weby.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

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

app.Run();

Middleware pro ochranu proti padělání:

Antiforgery token je ověřen pouze v případě, že:

  • Koncový bod obsahuje metadata implementující IAntiforgeryMetadata, kde RequiresValidation=true.
  • Metoda HTTP přidružená ke koncovému bodu je relevantní metoda HTTP. Relevantní metody jsou všechny HTTP metody kromě TRACE, OPTIONS, HEAD a GET.
  • Požadavek je propojený s platným koncovým bodem.

Další informace naleznete v tématu Antiforgery s Minimal APIs.

Nové IResettable rozhraní v ObjectPool

Microsoft.Extensions.ObjectPool poskytuje podporu pro sdružování instancí objektů v paměti. Aplikace můžou fond objektů použít, pokud jsou hodnoty nákladné k přidělení nebo inicializaci.

V této verzi jsme usnadnili používání fondu objektů přidáním IResettable rozhraní. Opakovaně použitelné typy je často potřeba obnovit zpět do výchozího stavu mezi použitím. IResettable typy se při vrácení do fondu objektů automaticky resetují.

Další informace naleznete v ukázce ObjectPool.

Nativní AOT

Byla přidána podpora pro funkci .NET native ahead-of-time (AOT). Aplikace publikované pomocí AOT můžou mít podstatně lepší výkon: menší velikost aplikace, menší využití paměti a rychlejší spouštění. Podpora nativního AOT je v současné době poskytována pro gRPC, minimal API a aplikace pracovní služby. Další informace najdete v tématu ASP.NET Core podpora nativního AOT a Kurz: Publikování aplikace ASP.NET Core pomocí nativní AOT. Informace o známých problémech s kompatibilitou ASP.NET Core a Native AOT naleznete v problému na GitHubu dotnet/core #8288.

Knihovny a nativní AOT

Mnoho oblíbených knihoven používaných v projektech ASP.NET Core má v současné době problémy s kompatibilitou při použití v projektu, který cílí na nativní AOT, například:

  • Použití reflexe ke kontrole a zjišťování typů.
  • Podmíněné načítání knihoven během běhu programu
  • Generování kódu za běhu pro implementaci funkcí.

Knihovny používající tyto dynamické funkce je potřeba aktualizovat, aby fungovaly s nativní AOT. Dají se aktualizovat pomocí nástrojů, jako jsou generátory zdrojů Roslyn.

Autoři knihoven, kteří chtějí podporovat nativní AOT, jsou doporučováni:

Nová šablona projektu

Nová šablona projektu ASP.NET Core Web API (nativní AOT) (krátký název webapiaot) vytvoří projekt s povoleným publikováním AOT. Další informace najdete v šabloně webového rozhraní API (nativní AOT).

Nová CreateSlimBuilder metoda

Metoda CreateSlimBuilder() použitá v šabloně webového rozhraní API (nativní AOT) inicializuje WebApplicationBuilder minimální ASP.NET základní funkce potřebné ke spuštění aplikace. Tato CreateSlimBuilder metoda obsahuje následující funkce, které jsou obvykle potřeba pro efektivní vývojové prostředí:

  • Konfigurace souboru JSON pro appsettings.json a appsettings.{EnvironmentName}.json.
  • Konfigurace tajných kódů uživatelů
  • Logování konzoly.
  • Konfigurace protokolování

Další informace naleznete v tématu MetodaCreateSlimBuilder.

Nová CreateEmptyBuilder metoda

Je tu další nová WebApplicationBuilder tovární metoda pro vytváření malých aplikací, které obsahují pouze nezbytné funkce: WebApplication.CreateEmptyBuilder(WebApplicationOptions options). Tento WebApplicationBuilder je vytvořen bez vestavěného chování. Aplikace, kterou sestaví, obsahuje pouze služby a middleware, které jsou explicitně nakonfigurované.

Tady je příklad použití tohoto rozhraní API k vytvoření malé webové aplikace:

var builder = WebApplication.CreateEmptyBuilder(new WebApplicationOptions());
builder.WebHost.UseKestrelCore();

var app = builder.Build();

app.Use(async (context, next) =>
{
    await context.Response.WriteAsync("Hello, World!");
    await next(context);
});

Console.WriteLine("Running...");
app.Run();

Publikování tohoto kódu pomocí nativní AOT pomocí .NET 8 Preview 7 na počítači s linuxem x64 vede k tomu, že se jedná o samostatný nativní spustitelný soubor o velikosti přibližně 8,5 MB.

Zmenšená velikost aplikace s konfigurovatelnou podporou HTTPS

Dále jsme snížili nativní binární velikost AOT pro aplikace, které nepotřebují podporu HTTPS nebo HTTP/3. Nepoužívá se HTTPS nebo HTTP/3 běžně u aplikací, které běží za proxy ukončením protokolu TLS (například hostované v Azure). Nová WebApplication.CreateSlimBuilder metoda tuto funkci ve výchozím nastavení vynechá. Můžete ho přidat voláním builder.WebHost.UseKestrelHttpsConfiguration() https nebo builder.WebHost.UseQuic() http/3. Další informace naleznete v tématu MetodaCreateSlimBuilder.

Serializace JSON typů generovaných kompilátorem IAsyncEnumerable<T>

Byly přidány nové funkce k System.Text.Json, aby lépe podporovaly nativní AOT. Tyto nové funkce přidávají možnosti pro režim generování zdroje System.Text.Json, protože AOT nepodporuje reflexi.

Jednou z nových funkcí je podpora serializace IAsyncEnumerable<T> JSON implementací implementovaných kompilátorem jazyka C#. Tato podpora otevře jejich použití v ASP.NET základních projektech nakonfigurovaných pro publikování nativní AOT.

Toto rozhraní API je užitečné ve scénářích, kdy obslužná rutina trasy používá yield return k asynchronnímu vrácení výčtu. Pokud chcete například materializovat řádky z databázového dotazu. Další informace najdete v tématu Podpora nevyjádřitelných typů v oznámení .NET 8 Preview 4.

Informace o dalších vylepšeních generování zdroje najdete v System.Text.Json tématu Vylepšení serializace v .NET 8.

Nejvyšší úrovně API rozhraní opatřená poznámkami pro výstrahy o oříznutí

Hlavní vstupní body k subsystémům, které nefungují spolehlivě s nativní AOT, jsou teď opatřeny poznámkami. Pokud jsou tyto metody volána z aplikace s povolenou nativní AOT, zobrazí se upozornění. Příklad: Následující kód vytvoří upozornění při vyvolání AddControllers, protože toto rozhraní API není bezpečné pro ořezávání a není podporováno nativním AOT.

Okno sady Visual Studio s upozorněním IL2026 v metodě AddControllers, která říká, že MVC v současné době nepodporuje nativní AOT.

Generátor delegátů pro žádosti

Aby byla minimální rozhraní API kompatibilní s nativním AOT, představujeme generátor požadavků delegátů (RDG). RDG je zdrojový generátor, který dělá to, co RequestDelegateFactory dělá (RDF). To znamená, že změní různé MapGet(), MapPost() a podobná volání na RequestDelegate instance přidružené k zadaným trasám. Ale místo toho, aby se při spuštění prováděla v paměti v aplikaci, rdG ji provede při kompilaci a vygeneruje kód jazyka C# přímo do projektu. RDG:

  • Odebere generování kódu za běhu.
  • Zajišťuje, že typy používané v rozhraních API jsou staticky analyzovatelné pomocí nativního řetězce nástrojů AOT.
  • Zajišťuje, že požadovaný kód není odstraněn.

Pracujeme na tom, abychom zajistili, že rdG podporuje co nejvíce funkcí minimálního rozhraní API, a proto je kompatibilní s nativní AOT.

RDG je automaticky povoleno v projektu, když je povoleno publikování s Native AOT. RdG lze ručně povolit, i když nepoužíváte nativní AOT nastavením <EnableRequestDelegateGenerator>true</EnableRequestDelegateGenerator> v souboru projektu. To může být užitečné při počátečním vyhodnocení připravenosti projektu na nativní AOT nebo snížení doby spuštění aplikace.

Lepší výkon s využitím průsečíků

Generátor delegáta požadavku používá novou funkci kompilátoru zachytávačů C# 12 k podpoře zachytávání volání metod minimal API Map se staticky generovanými variantami při běhu. Použití průsečíků vede ke zvýšení výkonu při spuštění aplikací zkompilovaných pomocí PublishAot.

Protokolování a zpracování výjimek v minimálních API generovaných v době kompilace.

Minimální rozhraní API generovaná za běhu podporují automatické protokolování (nebo vyvolávání výjimek ve vývojových prostředích), když dojde k selhání vazby parametrů. .NET 8 zavádí stejnou podporu pro API generovaná v době kompilace prostřednictvím Request Delegate Generatoru (RDG). Další informace naleznete v tématu Protokolování a zpracování výjimek v minimálních rozhraních API generovaných v době kompilace.

AOT a System.Text.Json

Minimální rozhraní API jsou optimalizovaná pro příjem a vracení JSON nálože pomocí System.Text.Json, takže platí i požadavky na kompatibilitu pro JSON a nativní AOT. Nativní kompatibilita AOT vyžaduje použití zdrojového generátoru System.Text.Json . Všechny typy, které jsou akceptovány jako parametry nebo vráceny z delegátů požadavků v Minimal API, musí být nakonfigurovány na JsonSerializerContext, který je registrován prostřednictvím injekce závislostí ASP.NET Core, například:

// Register the JSON serializer context with DI
builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonSerializerContext.Default);
});

...

// Add types used in the minimal API app to source generated JSON serializer content
[JsonSerializable(typeof(Todo[]))]
internal partial class AppJsonSerializerContext : JsonSerializerContext
{

}

Další informace o TypeInfoResolverChain rozhraní API najdete v následujících zdrojích informací:

Knihovny a nativní AOT

Mnoho běžných knihoven dostupných pro projekty ASP.NET Core má dnes některé problémy s kompatibilitou, pokud se používají v projektu, který cílí na nativní AOT. Oblíbené knihovny často využívají dynamické funkce reflexe .NET ke kontrole a zjišťování typů, podmíněnému načítání knihoven za běhu a generování kódu za běhu pro implementaci jejich funkcí. Tyto knihovny je potřeba aktualizovat, aby fungovaly s nativní AOT pomocí nástrojů, jako jsou generátory zdrojů Roslyn.

Autořům knihoven, kteří chtějí získat více informací o přípravě svých knihoven pro nativní AOT, je doporučeno začít s přípravou knihovny na ořezávání a získáním více informací o požadavcích na kompatibilitu nativního AOT.

Kestrel a HTTP.sys servery

Existuje několik nových funkcí pro Kestrel a HTTP.sys.

Podpora pojmenovaných kanálů v Kestrel

Pojmenované kanály jsou oblíbenou technologií pro vytváření komunikace mezi procesy (IPC) mezi aplikacemi pro Windows. Teď můžete vytvořit server IPC pomocí .NET Kestrela pojmenovaných kanálů.

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenNamedPipe("MyPipeName");
});

Další informace o této funkci a použití rozhraní .NET a gRPC k vytvoření serveru a klienta IPC naleznete v tématu Komunikace mezi procesy s gRPC.

Vylepšení výkonu transportu pojmenovaných kanálů

Vylepšili jsme výkon připojení pojmenovaného kanálu. KestrelPojmenovaný přenos kanálu teď přijímá připojení paralelně a znovu používá NamedPipeServerStream instance.

Doba vytvoření 100 000 připojení:

  • Před : 5,916 sekund
  • Za : 2,374 sekund

Podpora HTTP/2 přes protokol TLS (HTTPS) v systému macOS v Kestrel

.NET 8 přidává do systému macOS podporu vyjednávání protokolu ALPN (Application-Layer Protocol Negotiation). ALPN je funkce PROTOKOLU TLS, která slouží k vyjednávání protokolu HTTP, který bude připojení používat. AlpN například umožňuje prohlížečům a dalším klientům HTTP požadovat připojení HTTP/2. Tato funkce je užitečná zejména pro aplikace gRPC, které vyžadují PROTOKOL HTTP/2. Další informace najdete v tématu Použijte HTTP/2 s webovým serverem ASP.NET CoreKestrel.

Sledování souborů certifikátů v Kestrel

Certifikáty TLS nakonfigurované podle cesty jsou nyní monitorovány pro změny, když je reloadOnChange předáno do KestrelServerOptions.Configure(). Změna souboru certifikátu se zpracovává stejně jako změna nakonfigurované cesty (to znamená, že se koncové body znovu načtou).

Všimněte si, že odstranění souborů se konkrétně nesledují, protože vznikají přechodně a dojde k chybovému ukončení serveru v případě, že nejsou přechodné.

Upozornění, když se zadané protokoly HTTP nepoužijí

Pokud je protokol TLS zakázaný a je k dispozici protokol HTTP/1.x, protokoly HTTP/2 a HTTP/3 budou zakázány, i když byly zadány. To může způsobit několik ošklivých překvapení, takže jsme přidali výstup upozornění, který vás upozorní, když k tomu dojde.

HTTP_PORTS a HTTPS_PORTS konfigurační klíče

Aplikace a kontejnery mají často jenom port pro naslouchání, například 80, bez dalších omezení, jako je hostitel nebo cesta. HTTP_PORTS a HTTPS_PORTS jsou nové konfigurační klíče, které umožňují zadat naslouchací porty pro Kestrel servery a HTTP.sys. Mohou být definovány pomocí předpon proměnných prostředí DOTNET_ nebo ASPNETCORE_, nebo přímo pomocí jiného vstupu konfigurace, jako je například appsettings.json. Každý z nich je seznam hodnot portů oddělený středníkem. Například:

ASPNETCORE_HTTP_PORTS=80;8080
ASPNETCORE_HTTPS_PORTS=443;8081

Toto je zkratka pro následující kód, který určuje schéma (HTTP nebo HTTPS) a libovolného hostitele nebo IP adresy:

ASPNETCORE_URLS=http://*:80/;http://*:8080/;https://*:443/;https://*:8081/

Další informace najdete v tématu Konfigurace koncových bodů pro webový server ASP.NET Core Kestrel a implementace webového serveru HTTP.sys v ASP.NET Core.

Název hostitele SNI v ITlsHandshakeFeature

Název hostitele Server Name Indication (SNI) je nyní zpřístupněn ve vlastnosti HostName rozhraní ITlsHandshakeFeature.

SNI je součástí procesu handshake protokolu TLS. Umožňuje klientům zadat název hostitele, ke kterému se pokouší připojit, když server hostuje více virtuálních hostitelů nebo domén. Aby bylo možné během procesu handshake prezentovat správný certifikát zabezpečení, musí server znát název hostitele vybraný pro každou žádost.

Obvykle se název hostitele zpracovává pouze v rámci zásobníku PROTOKOLU TLS a slouží k výběru odpovídajícího certifikátu. Pokud tuto informaci v aplikaci zpřístupníte, mohou ji ostatní komponenty využívat pro účely, jako je diagnostika, omezování rychlosti, směrování a fakturace.

Zveřejnění názvu hostitele je užitečné pro rozsáhlé služby, které spravují tisíce vazeb SNI. Tato funkce může výrazně zlepšit efektivitu ladění během eskalací ze strany zákazníků. Vyšší transparentnost umožňuje rychlejší řešení problémů a vyšší spolehlivost služeb.

Další informace naleznete v sekci ITlsHandshakeFeature.HostName.

IHttpSysRequestTimingFeature

[IHttpSysRequestTimingFeature](https://source.dot.net/#Microsoft.AspNetCore.Server.HttpSys/IHttpSysRequestTimingFeature.cs,3c5dc86dc837b1f4) poskytuje podrobné informace o časování požadavků při použití [HTTP.sys serveru](xref:fundamentals/servers /httpsys) a [Hostování v procesu se službou IIS](xref:host-and-deploy/iis/in-process-hosting?view=aspnetcore-8.0&preserve-view=true#ihsrtf8): [IHttpSysRequestTimingFeature.TryGetTimestamp](https://source.dot.net/#Microsoft.AspNetCore.Server.HttpSys/IHttpSysRequestTimingFeature.cs,3c5dc86dc837b1f4) načte časové razítko pro zadaný typ časování: 
using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Server.HttpSys;
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseHttpSys();

var app = builder.Build();

app.Use((context, next) =>
{
    var feature = context.Features.GetRequiredFeature<IHttpSysRequestTimingFeature>();

    var loggerFactory = context.RequestServices.GetRequiredService<ILoggerFactory>();
    var logger = loggerFactory.CreateLogger("Sample");

    var timingType = HttpSysRequestTimingType.RequestRoutingEnd;

    if (feature.TryGetTimestamp(timingType, out var timestamp))
    {
        logger.LogInformation("Timestamp {timingType}: {timestamp}",
                                          timingType, timestamp);
    }
    else
    {
        logger.LogInformation("Timestamp {timingType}: not available for the "
                                           + "current request",    timingType);
    }

    return next(context);
});

app.MapGet("/", () => Results.Ok());

app.Run();

Další informace najdete v tématu Získání podrobných informací o načasování pomocí IHttpSysRequestTimingFeature a informací o časování a hostování v procesu se službou IIS.

HTTP.sys: Podpora volitelného zapnutí vyrovnávací paměti odpovědí v režimu jádra

V některých scénářích můžou velké objemy malých zápisů s vysokou latencí způsobit významný dopad na HTTP.sysvýkon . Tento důsledek je způsoben nedostatkem Pipe vyrovnávací paměti v implementaci HTTP.sys. Pro zvýšení výkonu v těchto scénářích byla do HTTP.sys přidána podpora ukládání odpovědí do vyrovnávací paměti. Povolte ukládání do vyrovnávací paměti nastavením httpSysOptions.EnableKernelResponseBuffering na true.

Ukládání odpovědí do vyrovnávací paměti by měla být povolena aplikací, která provádí synchronní vstupně-výstupní operace nebo asynchronní vstupně-výstupní operace s maximálně jedním nevyřízeným zápisem najednou. V těchto scénářích může ukládání odpovědí do vyrovnávací paměti výrazně zlepšit propustnost u připojení s vysokou latencí.

Aplikace, které používají asynchronní vstupně-výstupní operace a které můžou mít najednou více než jeden zápis, by tento příznak neměly používat. Povolením tohoto příznaku může dojít k vyššímu využití procesoru a paměti protokolem HTTP.Sys.

Ověřování a autorizace

.NET 8 přidává nové funkce pro ověřování a autorizaci.

Identity Koncové body rozhraní API

MapIdentityApi<TUser> je nová metoda rozšíření, která přidává dva koncové body rozhraní API (/register a /login). Hlavním cílem MapIdentityApi je umožnit vývojářům snadné použití ASP.NET Core Identity pro ověřování v jednostránkových aplikacích (SPA) nebo aplikacích založených na JavaScriptu Blazor. Místo použití výchozího uživatelského rozhraní poskytovaného službou ASP.NET Core Identity, která je založená na Razor stránkách, MapIdentityApi přidává koncové body rozhraní JSON API, které jsou vhodnější pro aplikace SPA a neprobíjené aplikace. Další informace najdete v tématu Identity Koncové body rozhraní API.

IAuthorizationRequirementData

Před vydáním .NET 8 bylo k přidání parametrizované politiky autorizace ke koncovému bodu nutné její implementace:

  • AuthorizeAttribute pro každou politiku.
  • AuthorizationPolicyProvider zpracovat vlastní politiku z řetězcově založeného kontraktu.
  • AuthorizationRequirement pro politiku.
  • AuthorizationHandler pro každý požadavek.

Představte si například následující kód napsaný pro .NET 7:

using AuthRequirementsData.Authorization;
using Microsoft.AspNetCore.Authorization;

var builder = WebApplication.CreateBuilder();

builder.Services.AddAuthentication().AddJwtBearer();
builder.Services.AddAuthorization();
builder.Services.AddControllers();
builder.Services.AddSingleton<IAuthorizationPolicyProvider, MinimumAgePolicyProvider>();
builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeAuthorizationHandler>();

var app = builder.Build();

app.MapControllers();

app.Run();

using Microsoft.AspNetCore.Mvc;

namespace AuthRequirementsData.Controllers;

[ApiController]
[Route("api/[controller]")]
public class GreetingsController : Controller
{
    [MinimumAgeAuthorize(16)]
    [HttpGet("hello")]
    public string Hello() => $"Hello {(HttpContext.User.Identity?.Name ?? "world")}!";
}

using Microsoft.AspNetCore.Authorization;
using System.Globalization;
using System.Security.Claims;

namespace AuthRequirementsData.Authorization;

class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeRequirement>
{
    private readonly ILogger<MinimumAgeAuthorizationHandler> _logger;

    public MinimumAgeAuthorizationHandler(ILogger<MinimumAgeAuthorizationHandler> logger)
    {
        _logger = logger;
    }

    // Check whether a given MinimumAgeRequirement is satisfied or not for a particular
    // context.
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                               MinimumAgeRequirement requirement)
    {
        // Log as a warning so that it's very clear in sample output which authorization
        // policies(and requirements/handlers) are in use.
        _logger.LogWarning("Evaluating authorization requirement for age >= {age}",
                                                                    requirement.Age);

        // Check the user's age
        var dateOfBirthClaim = context.User.FindFirst(c => c.Type ==
                                                                 ClaimTypes.DateOfBirth);
        if (dateOfBirthClaim != null)
        {
            // If the user has a date of birth claim, check their age
            var dateOfBirth = Convert.ToDateTime(dateOfBirthClaim.Value, CultureInfo.InvariantCulture);
            var age = DateTime.Now.Year - dateOfBirth.Year;
            if (dateOfBirth > DateTime.Now.AddYears(-age))
            {
                // Adjust age if the user hasn't had a birthday yet this year.
                age--;
            }

            // If the user meets the age criterion, mark the authorization requirement
            // succeeded.
            if (age >= requirement.Age)
            {
                _logger.LogInformation("Minimum age authorization requirement {age} satisfied",
                                         requirement.Age);
                context.Succeed(requirement);
            }
            else
            {
                _logger.LogInformation("Current user's DateOfBirth claim ({dateOfBirth})" +
                    " does not satisfy the minimum age authorization requirement {age}",
                    dateOfBirthClaim.Value,
                    requirement.Age);
            }
        }
        else
        {
            _logger.LogInformation("No DateOfBirth claim present");
        }

        return Task.CompletedTask;
    }
}

Kompletní ukázka pro .NET 7 nebo starší je ukázková aplikace OldStyleAuthRequirements (dotnet/AspNetCore.Docs.Samples úložiště GitHub) (jak stáhnout).

.NET 8 zavádí IAuthorizationRequirementData rozhraní. Rozhraní IAuthorizationRequirementData umožňuje definici atributu určit požadavky přidružené k zásadám autorizace. Pomocí IAuthorizationRequirementData lze předchozí vlastní kód autorizační politiky napsat s menším počtem řádků. Aktualizovaný Program.cs soubor:

using AuthRequirementsData.Authorization;
using Microsoft.AspNetCore.Authorization;
  
var builder = WebApplication.CreateBuilder();
  
builder.Services.AddAuthentication().AddJwtBearer();
builder.Services.AddAuthorization();
builder.Services.AddControllers();
-builder.Services.AddSingleton<IAuthorizationPolicyProvider, MinimumAgePolicyProvider>();
builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeAuthorizationHandler>();
  
var app = builder.Build();
  
app.MapControllers();
  
app.Run();

Aktualizovaný MinimumAgeAuthorizationHandler:

using Microsoft.AspNetCore.Authorization;
using System.Globalization;
using System.Security.Claims;

namespace AuthRequirementsData.Authorization;

class MinimumAgeAuthorizationHandler(ILogger<MinimumAgeAuthorizationHandler> logger) 
-    : AuthorizationHandler<MinimumAgeRequirement>
+    : AuthorizationHandler<MinimumAgeAuthorizeAttribute>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
-       MinimumAgeRequirement requirement)
+       MinimumAgeAuthorizeAttribute requirement)
    {
        ...
    }
}

Aktualizovaná ukázka je ukázková aplikace AuthRequirementsData (dotnet/AspNetCore.Docs.Samples úložiště GitHub) (jak stáhnout).

Další informace najdete v tématu Vlastní zásady autorizace s IAuthorizationRequirementData.

Zabezpečení koncových bodů uživatelského rozhraní Swagger

Koncové body uživatelského rozhraní Swagger je teď možné zabezpečit v produkčních prostředích voláním MapSwagger().RequireAuthorization. Další informace najdete v tématu Zabezpečení koncových bodů uživatelského rozhraní Swaggeru.

Miscellaneous

Následující části popisují různé nové funkce v ASP.NET Core v .NET 8.

Podpora klíčových služeb v oboru injektáže závislostí

Keyovaná služba odkazuje na mechanismus pro registraci a načítání služeb Dependency Injection (DI) pomocí klíčů. Služba je přidružena ke klíči voláním AddKeyedSingleton (nebo AddKeyedScopedAddKeyedTransient) pro jeho registraci. Přístup k registrované službě zadáním klíče s atributem [FromKeyedServices] . Následující kód ukazuje, jak používat služby s klíči:

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.SignalR;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddKeyedSingleton<ICache, BigCache>("big");
builder.Services.AddKeyedSingleton<ICache, SmallCache>("small");
builder.Services.AddControllers();

var app = builder.Build();

app.MapGet("/big", ([FromKeyedServices("big")] ICache bigCache) => bigCache.Get("date"));
app.MapGet("/small", ([FromKeyedServices("small")] ICache smallCache) =>
                                                               smallCache.Get("date"));

app.MapControllers();

app.Run();

public interface ICache
{
    object Get(string key);
}
public class BigCache : ICache
{
    public object Get(string key) => $"Resolving {key} from big cache.";
}

public class SmallCache : ICache
{
    public object Get(string key) => $"Resolving {key} from small cache.";
}

[ApiController]
[Route("/cache")]
public class CustomServicesApiController : Controller
{
    [HttpGet("big-cache")]
    public ActionResult<object> GetOk([FromKeyedServices("big")] ICache cache)
    {
        return cache.Get("data-mvc");
    }
}

public class MyHub : Hub
{
    public void Method([FromKeyedServices("small")] ICache cache)
    {
        Console.WriteLine(cache.Get("signalr"));
    }
}

Šablony projektů sady Visual Studio pro aplikace SPA s back-endem ASP.NET Core

Šablony projektů sady Visual Studio se teď doporučují k vytváření jednostrákových aplikací (SPA), které mají back-end ASP.NET Core. K dispozici jsou šablony, které vytvářejí aplikace založené na technologiích JavaScriptu, jako jsou Angular, React a Vue. Tyto šablony:

  • Vytvořte řešení sady Visual Studio s front-endovým projektem a back-endovým projektem.
  • Pro front-end použijte typ projektu sady Visual Studio pro JavaScript a TypeScript (.esproj).
  • Pro back-end použijte projekt ASP.NET Core.

Další informace o šablonách sady Visual Studio a o tom, jak získat přístup ke starším šablonám, najdete v tématu Přehled jednostrákových aplikací (SPA) v ASP.NET Core.

Podpora obecných atributů

Atributy, které dříve vyžadovaly Type parametr, jsou nyní k dispozici v čistějších obecných variantách. To je možné pomocí podpory obecných atributů v jazyce C# 11. Například syntaxi pro přidávání poznámek k typu odpovědi akce lze upravit následujícím způsobem:

[ApiController]
[Route("api/[controller]")]
public class TodosController : Controller
{
  [HttpGet("/")]
- [ProducesResponseType(typeof(Todo), StatusCodes.Status200OK)]
+ [ProducesResponseType<Todo>(StatusCodes.Status200OK)]
  public Todo Get() => new Todo(1, "Write a sample", DateTime.Now, false);
}

Obecné varianty jsou podporovány pro následující atributy:

  • [ProducesResponseType<T>]
  • [Produces<T>]
  • [MiddlewareFilter<T>]
  • [ModelBinder<T>]
  • [ModelMetadataType<T>]
  • [ServiceFilter<T>]
  • [TypeFilter<T>]

Analýza kódu v aplikacích ASP.NET Core

Nové analyzátory uvedené v následující tabulce jsou k dispozici v .NET 8.

Diagnostické ID Přerušení nebo nepřerušený Description
ASP0016 Nonbreaking Nevrací hodnotu z RequestDelegate
ASP0019 Nonbreaking Doporučujeme použít IHeaderDictionary.Append nebo indexer
ASP0020 Nonbreaking Komplexní typy odkazované podle parametrů trasy musí být parsovatelné.
ASP0021 Nonbreaking Návratový typ metody BindAsync musí být ValueTask<T>
ASP0022 Nonbreaking Byl zjištěn konflikt tras mezi zpracováním tras
ASP0023 Nonbreaking MVC: Detekován konflikt trasy mezi správci tras
ASP0024 Nonbreaking Zpracovatel trasy má více parametrů s atributem [FromBody]
ASP0025 Nonbreaking Použijte AddAuthorizationBuilder

Nástroje pro směrování

ASP.NET Core je postavený na směrování. Minimální rozhraní API, webová rozhraní API, Razor stránky a Blazor používají trasy k přizpůsobení procesu mapování požadavků HTTP na kód.

V .NET 8 jsme investovali do sady nových funkcí, aby se směrování snadněji naučilo a používalo. Mezi tyto nové funkce patří:

Další informace naleznete v tématu Nástroje směrování v .NET 8.

ASP.NET Core metriky

Měřicí ukazatele jsou zaznamenávány v průběhu času a nejčastěji se používají ke sledování výkonu aplikace a vytváření upozornění. Například čítač, který hlásí neúspěšné požadavky HTTP, se může zobrazit na řídicích panelech nebo generovat výstrahy, když selhání překročí prahovou hodnotu.

Tato verze Preview přidává nové metriky v celém ASP.NET Core pomocí System.Diagnostics.Metrics. Metrics je moderní API pro reportování a shromažďování informací o aplikacích.

Metriky nabízejí mnoho vylepšení v porovnání s existujícími čítači událostí:

  • Nové druhy měření pomocí čítačů, měřidla a histogramů
  • Výkonné výkaznictví s víceúrovňovými hodnotami.
  • Integrace do širšího ekosystému nativního pro cloud díky sladění se standardy OpenTelemetry.

Byly přidány metriky pro hostování KestrelASP.NET Core a SignalR. Další informace naleznete v tématu System.Diagnostics.Metrics.

IExceptionHandler

IExceptionHandler je nové rozhraní, které vývojářům poskytuje zpětné volání pro zpracování známých výjimek na centrálním místě.

IExceptionHandler implementace jsou registrovány voláním IServiceCollection.AddExceptionHandler<T>. Je možné přidat více implementací a volají se v pořadí, v jakém byly zaregistrovány. Pokud obslužná rutina výjimky zpracovává požadavek, může vrátit true, aby zastavila zpracování. Pokud žádná obslužná rutina výjimky nezpracuje výjimku, ovládací prvek se vrátí do výchozího chování a možností z middlewaru.

Další informace naleznete v tématu IExceptionHandler.

Vylepšené možnosti ladění

Atributy přizpůsobení ladění byly přidány do typů, jako jsou HttpContext, HttpRequest, HttpResponse, ClaimsPrincipal, a WebApplication. ** Vylepšený ladicí nástroj pro tyto typy usnadňuje hledání důležitých informací v debuggeru integrovaného vývojového prostředí. Následující snímky obrazovky ukazují rozdíl, který tyto atributy způsobují v zobrazení HttpContextladicího programu.

.NET 7:

Nepřehledné zobrazení typu HttpContext v debuggeru v .NET 7

.NET 8:

Užitečné zobrazení při ladění typu HttpContext v .NET 8.

Zobrazení v ladicím programu pro WebApplication zvýrazňuje důležité informace, jako jsou nakonfigurované koncové body, middleware a hodnoty IConfiguration.

.NET 7:

Nepřínosné zobrazení typu WebApplication v ladicím programu v .NET 7.

.NET 8:

Užitečné zobrazení ladění pro typ WebApplication v .NET 8.

Další informace o vylepšeních ladění v .NET 8 viz:

IPNetwork.Parse a TryParse

Nové Parse a TryParse metody na IPNetwork přidávají podporu pro vytvoření IPNetwork pomocí vstupního řetězce ve formátu CIDR nebo ve "zápisu lomítka".

Tady jsou příklady IPv4:

// Using Parse
var network = IPNetwork.Parse("192.168.0.1/32");

// Using TryParse
bool success = IPNetwork.TryParse("192.168.0.1/32", out var network);

// Constructor equivalent
var network = new IPNetwork(IPAddress.Parse("192.168.0.1"), 32);

Tady jsou příklady pro protokol IPv6:

// Using Parse
var network = IPNetwork.Parse("2001:db8:3c4d::1/128");

// Using TryParse
bool success = IPNetwork.TryParse("2001:db8:3c4d::1/128", out var network);

// Constructor equivalent
var network = new IPNetwork(IPAddress.Parse("2001:db8:3c4d::1"), 128);

Ukládání výstupu do mezipaměti využívající Redis

ASP.NET Core v .NET 8 přidává podporu pro použití Redis jako distribuované mezipaměti pro ukládání výstupu do mezipaměti. Ukládání výstupu do mezipaměti je funkce, která aplikaci umožňuje ukládat výstup do mezipaměti minimálního koncového bodu rozhraní API, akce kontroleru nebo Razor stránky. Další informace naleznete v tématu Ukládání výstupu do mezipaměti.

Middleware pro zkrat po směrování

Když se směrování shoduje s koncovým bodem, obvykle umožňuje běh zbytku potrubí middlewaru před vyvoláním logiky koncového bodu. Služby můžou snížit využití prostředků filtrováním známých požadavků v rané fázi zpracování. Metodu ShortCircuit rozšíření použijte, aby směrování okamžitě vyvolalo logiku koncového bodu a poté ukončilo požadavek. Například daná trasa nemusí procházet ověřováním nebo middlewarem CORS. Následující příklad přeruší žádosti, které odpovídají /short-circuit cestě.

app.MapGet("/short-circuit", () => "Short circuiting!").ShortCircuit();

Pomocí metody MapShortCircuit můžete nastavit zkrat pro více tras najednou tím, že předáte pole parametrů s předponami URL. Například prohlížeče a roboti často testují servery pro dobře známé cesty jako robots.txt a favicon.ico. Pokud aplikace tyto soubory nemá, může jeden řádek kódu nakonfigurovat obě trasy:

app.MapShortCircuit(404, "robots.txt", "favicon.ico");

Další informace najdete v tématu Zkrácení middleware po směrování.

Rozšiřitelnost middlewaru protokolování HTTP

Middleware pro protokolování HTTP má několik nových funkcí:

  • HttpLoggingFields.Duration: Pokud je tato možnost povolená, middleware vygeneruje na konci požadavku nový protokol a odpověď, která měří celkovou dobu potřebnou ke zpracování. Toto nové pole bylo přidáno do HttpLoggingFields.All sady.
  • HttpLoggingOptions.CombineLogs: Pokud je tato možnost povolená, middleware konsoliduje všechny své aktivní záznamy pro žádost a odezvu do jednoho protokolu na konci. Jedna zpráva protokolu obsahuje požadavek, text požadavku, odpověď, text odpovědi a dobu trvání.
  • IHttpLoggingInterceptor: Nové rozhraní pro službu, která se dá implementovat a zaregistrovat (pomocí AddHttpLoggingInterceptor) pro příjem zpětného volání jednotlivých požadavků a odpovědí pro přizpůsobení podrobností, které se zaprotokolují. Nejprve se použijí všechna nastavení protokolu specifická pro koncový bod a pak je možné je v těchto zpětných voláních přepsat. Implementace může:
    • Zrevidujte požadavek a odpověď.
    • Povolte nebo zakažte libovolný HttpLoggingFields.
    • Upravte, kolik textu požadavku nebo odpovědi se protokoluje.
    • Přidejte do protokolů vlastní pole.

Další informace najdete v tématu Protokolování HTTP v .NET a ASP.NET Core.

Nová rozhraní API v řešení ProblemDetails pro podporu odolnějších integrací

V rozhraní .NET 7 byla služba ProblemDetails představena za účelem zlepšení prostředí pro generování chybových odpovědí, které splňují specifikaci ProblemDetails. V .NET 8 se přidalo nové rozhraní API, které usnadňuje implementaci náhradního chování, pokud IProblemDetailsService není možné generovat ProblemDetails. Následující příklad ukazuje použití nového TryWriteAsync rozhraní API:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler(exceptionHandlerApp =>
{
    exceptionHandlerApp.Run(async httpContext =>
    {
        var pds = httpContext.RequestServices.GetService<IProblemDetailsService>();
        if (pds == null
            || !await pds.TryWriteAsync(new() { HttpContext = httpContext }))
        {
            // Fallback behavior
            await httpContext.Response.WriteAsync("Fallback: An error occurred.");
        }
    });
});

app.MapGet("/exception", () =>
{
    throw new InvalidOperationException("Sample Exception");
});

app.MapGet("/", () => "Test by calling /exception");

app.Run();

Další informace naleznete v tématu IProblemDetailsService náhradní

Zásadní změny

V článcích o zásadních změnách v .NET najdete zásadní změny, které se můžou použít při upgradu aplikace na novější verzi .NET.

Dodatečné zdroje

  • Last updated on