Sdílet prostřednictvím


Novinky v ASP.NET Core 9.0

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

Tento článek byl aktualizován pro .NET 9 Preview 5.

Blazor

Tato část popisuje nové funkce pro Blazor.

.NET MAUIBlazor Hybrid a šablona řešení webové aplikace

Nová šablona řešení usnadňuje vytváření .NET MAUI nativních a Blazor webových klientských aplikací, které sdílejí stejné uživatelské rozhraní. Tato šablona ukazuje, jak vytvářet klientské aplikace, které maximalizují opakované použití kódu a cílí na Android, iOS, Mac, Windows a Web.

Mezi klíčové funkce této šablony patří:

  • Možnost zvolit Blazor interaktivní režim vykreslování pro webovou aplikaci
  • Automatické vytváření příslušných projektů, včetně Blazor webové aplikace (globálního interaktivního automatického .NET MAUIBlazor Hybrid vykreslování) a aplikace
  • Vytvořené projekty používají ke správě komponent uživatelského rozhraní Razor knihovnu sdílených Razor tříd (RCL).
  • Součástí ukázkového kódu je použití injektáže závislostí k poskytování různých implementací rozhraní pro Blazor Hybrid aplikaci a Blazor webovou aplikaci.

Pokud chcete začít, nainstalujte sadu .NET 9 SDK a nainstalujte .NET MAUI úlohu, která obsahuje šablonu:

dotnet workload install maui

Pomocí následujícího příkazu vytvořte řešení ze šablony projektu v příkazovém prostředí:

dotnet new maui-blazor-web

Šablona je také k dispozici v sadě Visual Studio.

Poznámka:

V současné době dojde k výjimce, pokud Blazor jsou režimy vykreslování definovány na úrovni jednotlivých stránek nebo komponent. Další informace naleznete v tématu BlazorWebView potřebuje způsob, jak povolit přepsání ResolveComponentForRenderMode (dotnet/aspnetcore #51235).

Další informace najdete v tématu Vytvoření .NET MAUIBlazor Hybrid aplikace s webovou Blazor aplikací.

Optimalizace doručování statických prostředků

MapStaticAssets je nový middleware, který pomáhá optimalizovat doručování statických prostředků v libovolné aplikaci ASP.NET Core, včetně Blazor aplikací.

Další informace najdete v některém z následujících zdrojů informací:

Zjišťování umístění vykreslování, interaktivity a přiřazeného režimu vykreslování za běhu

Zavedli jsme nové rozhraní API navržené tak, aby zjednodušilo proces dotazování stavů komponent za běhu. Toto rozhraní API poskytuje následující možnosti:

  • Určete aktuální umístění spuštění komponenty: To může být zvlášť užitečné pro ladění a optimalizaci výkonu komponent.
  • Zkontrolujte, jestli je komponenta spuštěná v interaktivním prostředí: To může být užitečné pro komponenty, které mají různá chování na základě interaktivity jejich prostředí.
  • Načtení přiřazeného režimu vykreslování pro komponentu: Pochopení režimu vykreslování může pomoct optimalizovat proces vykreslování a zlepšit celkový výkon komponenty.

Vylepšené možnosti opětovného připojení na straně serveru:

Ve výchozím prostředí pro opětovné připojení na straně serveru jsme provedli následující vylepšení:

  • Když se uživatel vrátí do aplikace s odpojeným okruhem, pokusí se o opětovné připojení okamžitě, a nečeká na dobu trvání dalšího intervalu opětovného připojení. Tím se zlepší uživatelské prostředí při navigaci do aplikace na kartě prohlížeče, která přešla do režimu spánku.

  • Když pokus o opětovné připojení dosáhne serveru, ale server už okruh vydal, dojde k automatické aktualizaci stránky. Tím zabráníte uživateli v ruční aktualizaci stránky, pokud pravděpodobně dojde k úspěšnému opětovnému připojení.

  • Časování opětovného připojení využívá vypočítanou strategii zpětného odpojení. Ve výchozím nastavení dochází k prvním několika pokusům o opětovné připojení v rychlém sledu bez intervalu opakování, než se mezi pokusy zavádějí vypočítaná zpoždění. Chování intervalu opakování můžete přizpůsobit zadáním funkce pro výpočet intervalu opakování, jak ukazuje následující příklad exponenciálního opakování:

    Blazor.start({
      circuit: {
        reconnectionOptions: {
          retryIntervalMilliseconds: (previousAttempts, maxRetries) => 
            previousAttempts >= maxRetries ? null : previousAttempts * 1000
        },
      },
    });
    
  • Styl výchozího uživatelského rozhraní pro opětovné připojení byl modernizován.

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

Zjednodušená serializace stavu ověřování pro Blazor Web Apps

Nová rozhraní API usnadňují přidávání ověřování do existující Blazor webové aplikace. Když vytvoříte novou Blazor webovou aplikaci s ověřováním pomocí jednotlivých účtů a povolíte interaktivitu založenou na WebAssembly, projekt zahrnuje vlastní AuthenticationStateProvider v serverových i klientských projektech.

Tito zprostředkovatelé přetékají stav ověřování uživatele do prohlížeče. Ověřování na serveru místo klienta umožňuje aplikaci přístup ke stavu ověřování během předkončování a před inicializováním Blazor WebAssembly modulu runtime.

Vlastní AuthenticationStateProvider implementace používají službu Persistent Component State Service (PersistentComponentState) k serializaci stavu ověřování do komentářů HTML a čtení zpět z WebAssembly k vytvoření nové AuthenticationState instance.

To funguje dobře, pokud jste začali ze Blazor šablony projektu Webové aplikace a vybrali možnost Individuální účty , ale pokud se pokoušíte přidat ověřování do existujícího projektu, je to hodně kódu, který se má implementovat sami nebo zkopírovat. Teď jsou k dispozici rozhraní API, která jsou teď součástí Blazor šablony projektu Webové aplikace, která se dají volat na serverových a klientských projektech, aby se přidala tato funkce:

  • AddAuthenticationStateSerialization: Přidá potřebné služby pro serializaci stavu ověřování na serveru.
  • AddAuthenticationStateDeserialization: Přidá nezbytné služby pro deserializaci stavu ověřování v prohlížeči.

Ve výchozím nastavení rozhraní API serializuje pouze název na straně serveru a deklarace rolí pro přístup v prohlížeči. Možnost může být předána tak, aby AddAuthenticationStateSerialization zahrnovala všechny deklarace identity.

Další informace najdete v následujících částech článku **:

Přidání stránek vykreslování na straně statického serveru (SSR) do globálně interaktivní Blazor webové aplikace

S vydáním .NET 9 je teď jednodušší přidat statické stránky SSR do aplikací, které přijímají globální interaktivitu.

Tento přístup je užitečný jenom v případě, že aplikace obsahuje konkrétní stránky, které nemůžou pracovat s interaktivním vykreslováním serveru nebo webAssembly. Můžete například použít tento přístup pro stránky, které jsou závislé na čtení a zápisu HTTP cookiea můžou pracovat pouze v cyklu požadavků a odpovědí místo interaktivního vykreslování. U stránek, které pracují s interaktivním vykreslováním, byste je neměli vynutit, aby používaly statické vykreslování SSR, protože je pro koncového uživatele méně efektivní a méně responzivní.

Označte libovolnou Razor stránku komponenty s novým [ExcludeFromInteractiveRouting] atributem přiřazeným direktivou @attributeRazor :

@attribute [ExcludeFromInteractiveRouting]

Použití atributu způsobí, že navigace na stránce se ukončí z interaktivního směrování. Příchozí navigace je nucena provést opětovné načtení celé stránky místo toho, aby se stránka přeložila prostřednictvím interaktivního směrování. Opětovné načtení celé stránky vynutí opětovné načtení kořenovou komponentu nejvyšší úrovně, obvykle komponentu (App.razorkomponentuApp), aby se znovu vyrovnala ze serveru, což aplikaci umožňuje přepnout do jiného režimu vykreslování nejvyšší úrovně.

Metoda HttpContext.AcceptsInteractiveRouting rozšíření umožňuje komponentě zjistit, zda [ExcludeFromInteractiveRouting] je použita na aktuální stránku.

V komponentě App použijte vzor v následujícím příkladu:

  • Stránky, které nejsou označené [ExcludeFromInteractiveRouting] jako výchozí režim InteractiveServer vykreslování s globální interaktivitou. Můžete nahradit InteractiveServerInteractiveWebAssembly nebo InteractiveAuto zadat jiný výchozí globální režim vykreslování.
  • Stránky s poznámkami o [ExcludeFromInteractiveRouting] přijetí statického SSR (PageRenderMode je přiřazeno null).
<!DOCTYPE html>
<html>
<head>
    ...
    <HeadOutlet @rendermode="@PageRenderMode" />
</head>
<body>
    <Routes @rendermode="@PageRenderMode" />
    ...
</body>
</html>

@code {
    [CascadingParameter]
    private HttpContext HttpContext { get; set; } = default!;

    private IComponentRenderMode? PageRenderMode
        => HttpContext.AcceptsInteractiveRouting() ? InteractiveServer : null;
}

Alternativou k použití HttpContext.AcceptsInteractiveRouting metody rozšíření je ruční čtení metadat koncového bodu pomocí HttpContext.GetEndpoint()?.Metadata.

Tato funkce se zabývá referenční dokumentací v režimech vykreslování ASP.NET CoreBlazor.

Injektáž konstruktoru

Razor komponenty podporují injektáž konstruktoru.

V následujícím příkladu částečná třída (za kódem) vloží NavigationManager službu pomocí primárního konstruktoru:

public partial class ConstructorInjection(NavigationManager navigation)
{
    protected NavigationManager Navigation { get; } = navigation;
}

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

Komprese protokolu Websocket pro komponenty interaktivního serveru

Komponenty interaktivního serveru ve výchozím nastavení umožňují kompresi připojení WebSocket a nastavují 'self'direktivu frame-ancestorsContent Security Policy (CSP), která povoluje pouze vkládání aplikace do <iframe> zdroje, ze kterého se aplikace obsluhuje při povolení komprese nebo při poskytnutí konfigurace kontextu Protokolu WebSocket.

Kompresi je možné zakázat nastavením na nullhodnotu ConfigureWebSocketOptions , která snižuje ohrožení zabezpečení aplikace na útok, ale může vést ke snížení výkonu:

.AddInteractiveServerRenderMode(o => o.ConfigureWebSocketOptions = null)

Nakonfigurujte přísnější frame-ancestors CSP s hodnotou 'none' (vyžaduje se jednoduché uvozovky), která umožňuje kompresi Protokolu WebSocket, ale brání prohlížečům v vložení aplikace do libovolné <iframe>:

.AddInteractiveServerRenderMode(o => o.ContentSecurityFrameAncestorsPolicy = "'none'")

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

Zpracování událostí složení klávesnice v Blazor

Nová KeyboardEventArgs.IsComposing vlastnost označuje, jestli je událost klávesnice součástí relace složení. Sledování stavu složení událostí klávesnice je zásadní pro zpracování mezinárodních metod zadávání znaků.

Přidání parametru OverscanCount do QuickGrid

Komponenta QuickGrid nyní zveřejňuje OverscanCount vlastnost, která určuje, kolik dalších řádků se vykresluje před a za viditelnou oblastí, když je povolená virtualizace.

Výchozí hodnota OverscanCount je 3. Následující příklad zvýší OverscanCount na 4:

<QuickGrid ItemsProvider="itemsProvider" Virtualize="true" OverscanCount="4">
    ...
</QuickGrid>

SignalR

Tato část popisuje nové funkce pro SignalR.

Podpora polymorfního typu ve SignalR službě Hubs

Metody centra teď můžou místo odvozené třídy přijmout základní třídu, aby bylo možné polymorfní scénáře. Základní typ musí být opatřen poznámkami, aby bylo možné polymorfismus.

public class MyHub : Hub
{
    public void Method(JsonPerson person)
    {
        if (person is JsonPersonExtended)
        {
        }
        else if (person is JsonPersonExtended2)
        {
        }
        else
        {
        }
    }
}

[JsonPolymorphic]
[JsonDerivedType(typeof(JsonPersonExtended), nameof(JsonPersonExtended))]
[JsonDerivedType(typeof(JsonPersonExtended2), nameof(JsonPersonExtended2))]
private class JsonPerson
{
    public string Name { get; set; }
    public Person Child { get; set; }
    public Person Parent { get; set; }
}

private class JsonPersonExtended : JsonPerson
{
    public int Age { get; set; }
}

private class JsonPersonExtended2 : JsonPerson
{
    public string Location { get; set; }
}

Minimální rozhraní API

Tato část popisuje nové funkce pro minimální rozhraní API.

Přidáno InternalServerError a InternalServerError<TValue> do TypedResults

Třída TypedResults je užitečným vozidlem pro vrácení odpovědí na stavový kód HTTP se silnými typy z minimálního rozhraní API. TypedResults nyní obsahuje metody a typy továrny pro vrácení odpovědí "500 Internal Server Error" z koncových bodů. Tady je příklad, který vrátí odpověď 500:

var app = WebApplication.Create();

app.MapGet("/", () => TypedResults.InternalServerError("Something went wrong!"));

app.Run();

OpenAPI

Integrovaná podpora generování dokumentů OpenAPI

Specifikace OpenAPI je standard pro popis rozhraní HTTP API. Standard umožňuje vývojářům definovat tvar rozhraní API, která se dají připojit k generátorům klientů, generátorům serverů, testovacím nástrojům, dokumentaci a dalším funkcím. V .NET 9 Preview poskytuje ASP.NET Core integrovanou podporu pro generování dokumentů OpenAPI představujících rozhraní API založená na kontroleru nebo minimální rozhraní API prostřednictvím balíčku Microsoft.AspNetCore.OpenApi .

Následující zvýrazněná volání kódu:

  • AddOpenApi a zaregistrujte požadované závislosti do kontejneru DI aplikace.
  • MapOpenApi a zaregistrujte požadované koncové body OpenAPI v trasách aplikace.
var builder = WebApplication.CreateBuilder();

builder.Services.AddOpenApi();

var app = builder.Build();

app.MapOpenApi();

app.MapGet("/hello/{name}", (string name) => $"Hello {name}"!);

app.Run();

Microsoft.AspNetCore.OpenApi Nainstalujte balíček do projektu pomocí následujícího příkazu:

dotnet add package Microsoft.AspNetCore.OpenApi --prerelease

Spusťte aplikaci a přejděte k openapi/v1.json zobrazení vygenerovaného dokumentu OpenAPI:

Dokument OpenAPI

Dokumenty OpenAPI lze také vygenerovat v době sestavení přidáním Microsoft.Extensions.ApiDescription.Server balíčku:

dotnet add package Microsoft.Extensions.ApiDescription.Server --prerelease

Do souboru projektu aplikace přidejte následující:

<PropertyGroup>
  <OpenApiDocumentsDirectory>$(MSBuildProjectDirectory)</OpenApiDocumentsDirectory>
  <OpenApiGenerateDocuments>true</OpenApiGenerateDocuments>
</PropertyGroup>

Spusťte a zkontrolujte dotnet build vygenerovaný JSsoubor ON v adresáři projektu.

Generování dokumentů OpenAPI v době sestavení

ASP.NET integrované generování dokumentů OpenAPI core poskytuje podporu pro různá přizpůsobení a možnosti. Poskytuje transformátory dokumentů a operací a umožňuje spravovat více dokumentů OpenAPI pro stejnou aplikaci.

Další informace o nových funkcích dokumentů OpenAPI pro ASP.NET Core najdete v nových dokumentech Microsoft.AspNetCore.OpenApi.

Ověřování a autorizace

Tato část popisuje nové funkce pro ověřování a autorizaci.

Přizpůsobení parametrů OIDC a OAuth

Obslužné rutiny ověřování OAuth a OIDC teď mají AdditionalAuthorizationParameters možnost usnadnit přizpůsobení parametrů autorizační zprávy, které jsou obvykle součástí řetězce dotazu přesměrování. V .NET 8 a starších verzích to vyžaduje vlastní OnRedirectToIdentityProvider metodu zpětného volání nebo přepsání BuildChallengeUrl ve vlastní obslužné rutině. Tady je příklad kódu .NET 8:

builder.Services.AddAuthentication().AddOpenIdConnect(options =>
{
    options.Events.OnRedirectToIdentityProvider = context =>
    {
        context.ProtocolMessage.SetParameter("prompt", "login");
        context.ProtocolMessage.SetParameter("audience", "https://api.example.com");
        return Task.CompletedTask;
    };
});

Předchozí příklad je teď možné zjednodušit následujícím kódem:

builder.Services.AddAuthentication().AddOpenIdConnect(options =>
{
    options.AdditionalAuthorizationParameters.Add("prompt", "login");
    options.AdditionalAuthorizationParameters.Add("audience", "https://api.example.com");
});

Konfigurace HTTP.sys rozšířených příznaků ověřování

Teď můžete nakonfigurovat HTTP_AUTH_EX_FLAG_ENABLE_KERBEROS_CREDENTIAL_CACHING příznaky a HTTP_AUTH_EX_FLAG_CAPTURE_CREDENTIAL HTTP.sys pomocí nových EnableKerberosCredentialCaching vlastností CaptureCredentials v HTTP.sys AuthenticationManager a optimalizovat způsob zpracování ověřování systému Windows. Příklad:

webBuilder.UseHttpSys(options =>
{
    options.Authentication.Schemes = AuthenticationSchemes.Negotiate;
    options.Authentication.EnableKerberosCredentialCaching = true;
    options.Authentication.CaptureCredentials = true;
});

Různé

Následující části popisují různé nové funkce.

Nová HybridCache knihovna

Rozhraní HybridCache API přemísní některé mezery v existujících IDistributedCache rozhraních API a IMemoryCache rozhraních API. Přidává také nové funkce, například:

  • Ochrana "Stampede", aby se zabránilo paralelnímu načítání stejné práce.
  • Konfigurovatelná serializace

HybridCache je navržený tak, aby nahradil stávající IDistributedCache a použití, IMemoryCache a poskytuje jednoduché rozhraní API pro přidání nového kódu do mezipaměti. Poskytuje jednotné rozhraní API pro ukládání do mezipaměti v procesu i mimo proces.

Pokud chcete zjistit, jak HybridCache je rozhraní API zjednodušené, porovnejte ho s kódem, který používá IDistributedCache. Tady je příklad, jak vypadá použití IDistributedCache :

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

To je hodně práce, abyste se dostali správně pokaždé, včetně věcí, jako je serializace. A ve scénáři neúspěšné mezipaměti můžete skončit s několika souběžnými vlákny, všechna získání chybějící mezipaměti, všechna načtení podkladových dat, veškerá serializace a odeslání dat do mezipaměti.

Abychom tento kód HybridCachezjednodušili a vylepšili, musíme nejprve přidat novou knihovnu Microsoft.Extensions.Caching.Hybrid:

<PackageReference Include="Microsoft.Extensions.Caching.Hybrid" Version="9.0.0" />

HybridCache Zaregistrujte službu, jako byste zaregistrovali implementaciIDistributedCache:

services.AddHybridCache(); // Not shown: optional configuration API.

Teď je možné většinu problémů s ukládáním do mezipaměti přesměrovat na HybridCache:

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this combination.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

Poskytujeme konkrétní implementaci HybridCache abstraktní třídy prostřednictvím injektáže závislostí, ale je zamýšleno, aby vývojáři mohli poskytovat vlastní implementace rozhraní API. Implementace HybridCache se zabývá vším, co souvisí s ukládáním do mezipaměti, včetně zpracování souběžných operací. Token cancel zde představuje kombinované zrušení všech souběžných volajících – nejen zrušení volajícího vidíme (to znamená token).

Scénáře s vysokou propustností je možné dále optimalizovat pomocí TState modelu, aby nedocházelo k určitým režijním nákladům na zachycené proměnné a zpětná volání jednotlivých instancí:

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync(string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // unique key for this combination
            (name, id), // all of the state we need for the final call, if needed
            static async (state, token) =>
                await SomeExpensiveOperationAsync(state.name, state.id, token),
            token: token
        );
    }
}

HybridCache používá nakonfigurovanou IDistributedCache implementaci ( pokud existuje) pro sekundární mezipaměť mimo proces, například pomocí Redis. Ale i bez IDistributedCache, HybridCache služba bude i nadále poskytovat mezipaměť v procesu a "razítko" ochranu.

Poznámka k opakovanému použití objektu

V typickém existujícím kódu, který používá IDistributedCache, každé načtení objektu z mezipaměti má za následek deserializaci. Toto chování znamená, že každý souběžný volající získá samostatnou instanci objektu, která nemůže komunikovat s jinými instancemi. Výsledkem je bezpečnost vláken, protože neexistuje riziko souběžných úprav stejné instance objektu.

Vzhledem k tomu, že se hodně HybridCache využití přizpůsobí existujícímu IDistributedCache kódu, zachová toto chování ve výchozím nastavení, HybridCache aby nedocházelo k chybám souběžnosti. Daný případ použití je však ze své podstaty bezpečný pro přístup z více vláken:

  • Pokud jsou typy uložené v mezipaměti neměnné.
  • Pokud kód neupraví.

V takových případech informujte HybridCache , že je bezpečné opakovaně používat instance pomocí:

  • Označení typu jako sealed. Klíčové sealed slovo v jazyce C# znamená, že třídu nelze dědit.
  • Použití atributu [ImmutableObject(true)] na něj Atribut [ImmutableObject(true)] označuje, že stav objektu nelze po vytvoření změnit.

Opětovným použitím instancí HybridCache může snížit režii přidělení procesoru a objektů spojených s deserializací podle volání. To může vést ke zlepšení výkonu ve scénářích, kdy jsou objekty uložené v mezipaměti velké nebo často přístupné.

Další HybridCache funkce

Podobně jako IDistributedCachepodporuje HybridCache odebrání pomocí klíče pomocí RemoveKeyAsync metody.

HybridCache poskytuje také volitelná rozhraní API pro IDistributedCache implementace, aby se zabránilo byte[] přidělení. Tuto funkci implementují verze Microsoft.Extensions.Caching.StackExchangeRedis Preview a Microsoft.Extensions.Caching.SqlServer balíčky.

Serializace se konfiguruje jako součást registrace služby s podporou typově specifických a generalizovaných serializátorů prostřednictvím WithSerializer metod a .WithSerializerFactory metod zřetězených AddHybridCache z volání. Ve výchozím nastavení knihovna zpracovává string a byte[] interně a používá System.Text.Json se pro všechno ostatní, ale můžete použít protobuf, xml nebo cokoli jiného.

HybridCache podporuje starší moduly runtime .NET až .NET Framework 4.7.2 a .NET Standard 2.0.

Další informace o HybridCacheknihovně HybridCache v ASP.NET Core

Vylepšení stránky výjimek pro vývojáře

Stránka výjimky pro vývojáře ASP.NET Core se zobrazí, když aplikace během vývoje vyvolá neošetřenou výjimku. Stránka výjimky vývojáře obsahuje podrobné informace o výjimce a požadavku.

Verze Preview 3 přidala metadata koncového bodu na stránku výjimky vývojáře. ASP.NET Core používá metadata koncového bodu k řízení chování koncových bodů, jako je směrování, ukládání odpovědí do mezipaměti, omezování rychlosti, generování OpenAPI a další. Následující obrázek znázorňuje nové informace o metadatech v Routing části stránky výjimky vývojáře:

Nové informace o metadatech na stránce výjimky vývojáře

Při testování stránky výjimek pro vývojáře byly identifikovány malé vylepšení životního cyklu. Odeslali je ve verzi Preview 4:

  • Lepší obtékání textu. Dlouhé cookiehodnoty, hodnoty řetězce dotazu a názvy metod už nepřidají vodorovné posuvníky prohlížeče.
  • Větší text, který se nachází v moderních designech.
  • Konzistentnější velikosti tabulek

Následující animovaný obrázek znázorňuje novou stránku výjimky vývojáře:

Stránka s výjimkou nového vývojáře

Vylepšení ladění slovníku

Zobrazení ladění slovníků a dalších kolekcí klíč-hodnota má vylepšené rozložení. Klíč se místo zřetězení s hodnotou zobrazí ve sloupci klíče ladicího programu. Následující obrázky ukazují starý a nový displej slovníku v ladicím programu.

Před:

Předchozí prostředí ladicího programu

Po:

Nové prostředí ladicího programu

ASP.NET Core obsahuje mnoho kolekcí klíč-hodnota. Toto vylepšené možnosti ladění platí pro:

  • Záhlaví HTTP
  • Řetězce dotazů
  • Formuláře
  • Cookies
  • Zobrazit data
  • Směrování dat
  • Funkce

Oprava chyby 503 během recyklace aplikace ve službě IIS

Ve výchozím nastavení mezi oznámením služby IIS o recyklaci nebo vypnutí dojde k 1sekundovém zpoždění a když služba ANCM řekne spravovanému serveru, aby se spustilo vypnutí. Zpoždění je možné konfigurovat prostřednictvím ANCM_shutdownDelay proměnné prostředí nebo nastavením nastavení obslužné rutiny shutdownDelay . Obě hodnoty jsou v milisekundách. Zpoždění spočívá hlavně ve snížení pravděpodobnosti závodu, kdy:

  • Služba IIS nezačala začínat požadavky na řazení do fronty pro přechod do nové aplikace.
  • ANCM začne odmítat nové požadavky, které přicházejí do staré aplikace.

Pomalejší počítače nebo počítače s těžším využitím procesoru můžou chtít tuto hodnotu upravit, aby se snížila pravděpodobnost 503.

Příklad nastavení shutdownDelay:

<aspNetCore processPath="dotnet" arguments="myapp.dll" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
  <handlerSettings>
    <!-- Milliseconds to delay shutdown by.
    this doesn't mean incoming requests will be delayed by this amount,
    but the old app instance will start shutting down after this timeout occurs -->
    <handlerSetting name="shutdownDelay" value="5000" />
  </handlerSettings>
</aspNetCore>

Oprava je v globálně nainstalovaném modulu ANCM, který pochází z hostitelské sady.

Optimalizace doručování statických webových prostředků

Vytváření výkonných webových aplikací zahrnuje optimalizaci doručování prostředků do prohlížeče. To zahrnuje mnoho aspektů, jako jsou:

MapStaticAssets je nový middleware, který pomáhá optimalizovat doručování statických prostředků v aplikaci. Je navržená tak, aby fungovala se všemi architekturami uživatelského rozhraní, včetně Blazor, Razor Pages a MVC. Obvykle se jedná o náhradu za UseStaticFiles.

MapStaticAssets funguje tak, že zkombinuje procesy sestavení a publikování a shromažďuje informace o všech statických prostředcích v aplikaci. Tyto informace pak knihovna modulu runtime využívá k efektivnímu poskytování těchto souborů do prohlížeče.

MapStaticAssets může nahradit UseStaticFiles ve většině situací, ale je optimalizovaná pro poskytování prostředků, o kterých má aplikace znalosti při sestavování a publikování. Pokud aplikace obsluhuje prostředky z jiných umístění, jako jsou disky nebo vložené prostředky, UseStaticFiles by se měly použít.

MapStaticAssetsposkytuje následující výhody, které nebyly nalezeny:UseStaticFiles

  • Komprese času sestavení pro všechny prostředky v aplikaci:
    • gzip během vývoje a gzip + brotli během publikování.
    • Všechny prostředky jsou komprimovány s cílem zmenšit velikost prostředků na minimum.
  • Obsah založenýETags: Pro Etags každý prostředek jsou řetězec kódovaný kódem Base64 hodnoty hash SHA-256 obsahu. Tím se zajistí, že prohlížeč znovu načte soubor pouze v případě, že se změnil jeho obsah.

Následující tabulka ukazuje původní a komprimované velikosti šablon stylů CSS a JS souborů ve výchozí Razor šabloně Stránky:

Soubor Původní Komprimované % redukce
bootstrap.min.css 163 17.5 89.26%
jquery.js 89.6 28 68.75%
bootstrap.min.js 78,5 20 74.52%
Celkem 331.1 65.5 80.20%

Následující tabulka uvádí původní a komprimované velikosti pomocí knihovny komponent uživatelského rozhraní Blazor Fluent:

Soubor Původní Komprimované % redukce
fluent.js 384 73 80.99%
fluent.css 94 11 88.30%
Celkem 478 84 82.43%

Pro celkem 478 KB nekomprimované na 84 kB komprimované.

Následující tabulka ukazuje původní a komprimované velikosti pomocí knihovny komponent MudBlazorBlazor :

Soubor Původní Komprimované Redukce
BlátoBlazor.min.css 541 37.5 93.07%
BlátoBlazor.min.js 47.4 9.2 80.59%
Celkem 588.4 46,7 92.07%

Optimalizace probíhá automaticky při použití MapStaticAssets. Při přidání nebo aktualizaci knihovny, například pomocí nového JavaScriptu nebo šablon stylů CSS, se prostředky optimalizují jako součást sestavení. Optimalizace je zvlášť přínosná pro mobilní prostředí, která můžou mít nižší šířku pásma nebo nespolehlivé připojení.

Povolení dynamické komprese na serveru vs. MapStaticAssets

MapStaticAssets má následující výhody oproti dynamické kompresi na serveru:

  • Je jednodušší, protože neexistuje žádná konfigurace specifická pro server.
  • Je výkonnější, protože prostředky se komprimují v době sestavení.
  • Umožňuje vývojáři strávit během procesu sestavení více času, aby se zajistilo, že prostředky mají minimální velikost.

Podívejte se na následující tabulku, která porovnává kompresi MudBlazor s dynamickou kompresí služby IIS a MapStaticAssets:

IIS gzip MapStaticAssets Redukce MapStaticAssets
≅ 90 37.5 59%