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í:
- Část Optimalizace doručování statických webových prostředků tohoto článku.
- ASP.NET základních Blazor statických souborů.
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 **:
- BlazorIdentity Uživatelské rozhraní (jednotlivé účty)
- Správa stavu ověřování ve Službě Blazor Web Apps
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 @attribute
Razor :
@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.razor
komponentuApp
), 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žimInteractiveServer
vykreslování s globální interaktivitou. Můžete nahraditInteractiveServer
InteractiveWebAssembly
neboInteractiveAuto
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řazenonull
).
<!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-ancestors
Content 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 null
hodnotu 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:
- Pokyny pro ASP.NET Core BlazorSignalR
- Pokyny ke zmírnění hrozeb pro interaktivní vykreslování na straně serveru ASP.NET Core Blazor
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:
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.
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 HybridCache
zjednoduš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 IDistributedCache
podporuje 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 HybridCache
knihovně 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:
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:
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:
Po:
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:
- Nastavení hlaviček ETag a Naposledy upravených
- Nastavení správných hlaviček ukládání do mezipaměti
- Použití middlewaru ukládání do mezipaměti
- Pokud je to možné, obsluhuje komprimované verze prostředků.
- Použití CDN k poskytování prostředků blíže k uživateli.
- Minifikace prostředků.
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.
MapStaticAssets
poskytuje následující výhody, které nebyly nalezeny:UseStaticFiles
- Komprese času sestavení pro všechny prostředky v aplikaci:
gzip
během vývoje agzip + 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
: ProEtags
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% |
Váš názor
https://aka.ms/ContentUserFeedback.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu:Odeslat a zobrazit názory pro