Share via

Novinky v ASP.NET Core 3.0

  • Článek

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

Blazor

Blazor je nová architektura v ASP.NET Core pro vytváření interaktivního webového uživatelského rozhraní na straně klienta pomocí .NET:

  • Vytvářejte bohaté interaktivní uživatelské rozhraní pomocí jazyka C#.
  • Sdílejte logiku aplikace na straně serveru a klienta napsanou v .NET.
  • Vykreslujte uživatelské rozhraní jako HTML a CSS pro širokou podporu prohlížečů, včetně mobilních prohlížečů.

Blazor podporované scénáře architektury:

  • Opakovaně použitelné komponenty uživatelského rozhraní (Razor komponenty)
  • Směrování na straně klienta
  • Rozložení součástí
  • Podpora injektáže závislostí
  • Formuláře a ověřování
  • Dodávání Razor komponent v Razor knihovnách tříd
  • Interoperabilita JavaScriptu

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

Blazor Server

Blazor oddělí logiku vykreslování komponent od způsobu použití aktualizací uživatelského rozhraní. Blazor Server poskytuje podporu pro hostování komponent Razor na serveru v aplikaci ASP.NET Core. Aktualizace uživatelského rozhraní se zpracovávají pomocí připojení SignalR. Blazor Server podporuje se v ASP.NET Core 3.0.

Blazor WebAssembly (Preview)

Blazor aplikace lze také spouštět přímo v prohlížeči pomocí modulu runtime .NET založeného na WebAssembly. Blazor WebAssembly je ve verzi Preview a nepodporuje se v ASP.NET Core 3.0. Blazor WebAssembly bude podporována v budoucí verzi ASP.NET Core.

Komponenty Razor

Blazor aplikace jsou sestavené ze součástí. Komponenty jsou samostatné bloky uživatelského rozhraní, jako je stránka, dialogové okno nebo formulář. Komponenty jsou normální třídy .NET, které definují logiku vykreslování uživatelského rozhraní a obslužné rutiny událostí na straně klienta. Můžete vytvářet bohaté interaktivní webové aplikace bez JavaScriptu.

Komponenty jsou Blazor obvykle vytvořené pomocí Razor syntaxe, což je přirozená směs HTML a jazyka C#. Razor komponenty jsou podobné Razor zobrazení Pages a MVC v tom, že oba používají Razor. Na rozdíl od stránek a zobrazení, které jsou založené na modelu odpovědi na požadavky, se komponenty používají speciálně pro zpracování složení uživatelského rozhraní.

gRPC

gRPC:

  • Je oblíbená vysoce výkonná architektura RPC (vzdálené volání procedur).

  • Nabízí přístup založený na kontraktech při vývoji rozhraní API.

  • Používá moderní technologie, jako jsou:

    • HTTP/2 pro přenos.
    • Vyrovnávací paměti protokolu jako jazyk popisu rozhraní.
    • Binární serializační formát.

  • Poskytuje funkce, jako jsou:

    • Authentication
    • Obousměrné streamování a řízení toku
    • Zrušení a vypršení časových limitů

Funkce gRPC ve ASP.NET Core 3.0 zahrnuje:

  • Grpc.AspNetCore: Architektura ASP.NET Core pro hostování služeb gRPC. GRPC na ASP.NET Core se integruje se standardními funkcemi ASP.NET Core, jako je protokolování, injektáž závislostí (DI), ověřování a autorizace.
  • Grpc.Net.Client: Klient gRPC pro .NET Core, který vychází ze známého HttpClientrozhraní .
  • Grpc.Net.ClientFactory: integrace klienta gRPC s HttpClientFactory.

Další informace naleznete v tématu Přehled gRPC v .NET.

SignalR

Pokyny k migraci najdete v tématu Aktualizace SignalR kódu . SignalR nyní se používá System.Text.Json k serializaci/deserializaci JSzpráv ON. Pokyny k obnovení serializátoru založeného na serializátoru Newtonsoft.Jsonnajdete v tématu Přepnutí na Newtonsoft.Json.

V JavaScriptu a klientech .NET pro SignalR, byla přidána podpora pro automatické opětovné připojení. Ve výchozím nastavení se klient pokusí znovu připojit okamžitě a v případě potřeby se po 2, 10 a 30 sekundách znovu připojit. Pokud se klient úspěšně znovu připojí, obdrží nové ID připojení. Automatické opětovné připojení je výslovný souhlas:

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .withAutomaticReconnect()
    .build();

Intervaly opětovného připojení je možné zadat předáním pole doby trvání založené na milisekundách:

.withAutomaticReconnect([0, 3000, 5000, 10000, 15000, 30000])
//.withAutomaticReconnect([0, 2000, 10000, 30000]) The default intervals.

Vlastní implementaci je možné předat pro úplnou kontrolu intervalů opětovného připojení.

Pokud opětovné připojení selže po posledním intervalu opětovného připojení:

  • Klient považuje připojení za offline.
  • Klient se přestane pokoušet znovu připojit.

Během opakovaných pokusů o připojení aktualizujte uživatelské rozhraní aplikace, aby uživatele informovalo, že se o opětovné připojení pokouší.

Pokud chcete poskytnout zpětnou vazbu k uživatelskému rozhraní při přerušení připojení, bylo rozhraní API klienta rozšířeno tak, SignalR aby zahrnovalo následující obslužné rutiny událostí:

  • onreconnecting: Umožňuje vývojářům zakázat uživatelské rozhraní nebo dát uživatelům vědět, že je aplikace offline.
  • onreconnected: Umožňuje vývojářům aktualizovat uživatelské rozhraní po opětovném vytvoření připojení.

Následující kód používá onreconnecting k aktualizaci uživatelského rozhraní při pokusu o připojení:

connection.onreconnecting((error) => {
    const status = `Connection lost due to error "${error}". Reconnecting.`;
    document.getElementById("messageInput").disabled = true;
    document.getElementById("sendButton").disabled = true;
    document.getElementById("connectionStatus").innerText = status;
});

Následující kód používá onreconnected k aktualizaci uživatelského rozhraní při připojení:

connection.onreconnected((connectionId) => {
    const status = `Connection reestablished. Connected.`;
    document.getElementById("messageInput").disabled = false;
    document.getElementById("sendButton").disabled = false;
    document.getElementById("connectionStatus").innerText = status;
});

SignalR 3.0 a novější poskytuje vlastní prostředek obslužným rutinům autorizace, pokud metoda centra vyžaduje autorizaci. Prostředek je instance HubInvocationContext. Mezi HubInvocationContext tyto položky patří:

  • HubCallerContext
  • Název volané metody centra.
  • Argumenty pro metodu centra.

Podívejte se na následující příklad aplikace chatovací místnosti, která umožňuje přihlášení více organizací přes Azure Active Directory. Každý, kdo má účet Microsoft, se může přihlásit k chatu, ale jenom členové vlastnící organizace můžou zakázat uživatele nebo zobrazit historii chatů uživatelů. Aplikace může omezit určité funkce od konkrétních uživatelů.

public class DomainRestrictedRequirement :
    AuthorizationHandler<DomainRestrictedRequirement, HubInvocationContext>,
    IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
        DomainRestrictedRequirement requirement,
        HubInvocationContext resource)
    {
        if (context.User?.Identity?.Name == null)
        {
            return Task.CompletedTask;
        }

        if (IsUserAllowedToDoThis(resource.HubMethodName, context.User.Identity.Name))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }

    private bool IsUserAllowedToDoThis(string hubMethodName, string currentUsername)
    {
        if (hubMethodName.Equals("banUser", StringComparison.OrdinalIgnoreCase))
        {
            return currentUsername.Equals("bob42@jabbr.net", StringComparison.OrdinalIgnoreCase);
        }

        return currentUsername.EndsWith("@jabbr.net", StringComparison.OrdinalIgnoreCase));
    }
}

V předchozím kódu DomainRestrictedRequirement slouží jako vlastní IAuthorizationRequirement. HubInvocationContext Vzhledem k tomu, že se předává parametr prostředku, může interní logika:

  • Zkontrolujte kontext, ve kterém se centrum volá.
  • Rozhodování o tom, jak uživateli umožnit spouštění jednotlivých metod centra

Jednotlivé metody centra je možné označit názvem zásady, které kód kontroluje za běhu. Když se klienti pokusí volat jednotlivé metody centra, obslužná rutina DomainRestrictedRequirement se spustí a řídí přístup k metodám. Na základě způsobu DomainRestrictedRequirement řízení přístupu:

  • Tuto metodu SendMessage můžou volat všichni přihlášení uživatelé.
  • Historii uživatelů můžou zobrazit jenom uživatelé, kteří se přihlásili pomocí @jabbr.net e-mailové adresy.
  • Uživatele z chatovací místnosti můžou zakázat jenom bob42@jabbr.net .
[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

    [Authorize("DomainRestricted")]
    public void BanUser(string username)
    {
    }

    [Authorize("DomainRestricted")]
    public void ViewUserHistory(string username)
    {
    }
}

DomainRestricted Vytvoření zásady může zahrnovat:

  • V Startup.cspřidání nové zásady.
  • Zadejte vlastní DomainRestrictedRequirement požadavek jako parametr.
  • DomainRestricted Registrace pomocí autorizačního middlewaru
services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalR Rozbočovače používají směrování koncových bodů. SignalR Připojení rozbočovače bylo dříve provedeno explicitně:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

V předchozí verzi potřebovali vývojáři připojit kontrolery, Razor stránky a rozbočovače na různých místech. Explicitní připojení vede k řadě téměř identických segmentů směrování:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

app.UseRouting(routes =>
{
    routes.MapRazorPages();
});

SignalR Rozbočovače 3.0 je možné směrovat pomocí směrování koncového bodu. Pomocí směrování koncového bodu je obvykle možné nakonfigurovat veškeré směrování v UseRouting:

app.UseRouting(routes =>
{
    routes.MapRazorPages();
    routes.MapHub<ChatHub>("hubs/chat");
});

ASP.NET Core 3.0 SignalR přidáno:

Streamování mezi klienty. Při streamování mezi klientem a serverem můžou metody na straně serveru přijímat instance typu IAsyncEnumerable<T> nebo ChannelReader<T>. V následující ukázce UploadStream jazyka C# metoda v centru obdrží datový proud řetězců z klienta:

public async Task UploadStream(IAsyncEnumerable<string> stream)
{
    await foreach (var item in stream)
    {
        // process content
    }
}

Klientské aplikace .NET můžou předat buď instanci IAsyncEnumerable<T> , nebo ChannelReader<T> jako stream argument výše uvedené UploadStream metody centra.

for Po dokončení smyčky a ukončení místní funkce se odešle dokončení datového proudu:

async IAsyncEnumerable<string> clientStreamData()
{
    for (var i = 0; i < 5; i++)
    {
        var data = await FetchSomeData();
        yield return data;
    }
}

await connection.SendAsync("UploadStream", clientStreamData());

Klientské aplikace v JavaScriptu SignalRSubject používají (nebo předmět jazyka RxJS) pro stream argument výše uvedené UploadStream metody centra.

let subject = new signalR.Subject();
await connection.send("StartStream", "MyAsciiArtStream", subject);

Kód JavaScriptu by mohl použít metodu subject.next pro zpracování řetězců, protože jsou zachyceny a připravené k odeslání na server.

subject.next("example");
subject.complete();

Pomocí kódu, jako jsou dva předchozí fragmenty kódu, je možné vytvořit prostředí streamování v reálném čase.

Nová JSserializace ON

ASP.NET Core 3.0 teď ve výchozím nastavení používá System.Text.Json pro JSserializaci ON:

  • Čtení a zápisy JSon asynchronně.
  • Je optimalizovaný pro text UTF-8.
  • Obvykle vyšší výkon než Newtonsoft.Json.

Pokud chcete přidat Json.NET do ASP.NET Core 3.0, přečtěte si téma Přidání podpory formátu ZALOŽENÉ na Newtonsoft.JsonJS.

Nové Razor direktivy

Následující seznam obsahuje nové Razor direktivy:

  • @attribute: Direktiva @attribute použije daný atribut na třídu vygenerované stránky nebo zobrazení. Například, @attribute [Authorize].
  • @implements: Direktiva @implements implementuje rozhraní pro vygenerovanou třídu. Například, @implements IDisposable.

IdentityServer4 podporuje ověřování a autorizaci webových rozhraní API a spA.

ASP.NET Core 3.0 nabízí ověřování v jednostráňových aplikacích (SPA) pomocí podpory autorizace webového rozhraní API. ASP.NET Core Identity pro ověřování a ukládání uživatelů se kombinuje se serverem Identity4 pro implementaci openID Připojení.

IdentityServer4 je rozhraní OpenID Připojení a OAuth 2.0 pro ASP.NET Core 3.0. Umožňuje následující funkce zabezpečení:

  • Ověřování jako služba (AaaS)
  • Jednotné přihlašování nebo vypnutí (SSO) u více typů aplikací
  • Řízení přístupu pro rozhraní API
  • Federační brána

Další informace najdete v dokumentaci k serveru 4 nebo v dokumentaci k ověřování a autorizaci pro služby SPAIdentity.

Ověřování pomocí certifikátu a protokolu Kerberos

Ověřování certifikátů vyžaduje:

  • Konfigurace serveru pro příjem certifikátů
  • Přidání ověřovacího middlewaru do Startup.Configuresouboru .
  • Přidání ověřovací služby certifikátu do Startup.ConfigureServices.
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(
        CertificateAuthenticationDefaults.AuthenticationScheme)
            .AddCertificate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Mezi možnosti ověřování certifikátů patří možnost:

  • Přijměte certifikáty podepsané svým držitelem.
  • Zkontrolujte odvolání certifikátu.
  • Zkontrolujte, jestli v něm má certifikát načítané správné příznaky použití.

Výchozí objekt zabezpečení uživatele je vytvořen z vlastností certifikátu. Objekt zabezpečení uživatele obsahuje událost, která umožňuje doplnění nebo nahrazení objektu zabezpečení. Další informace najdete v tématu Konfigurace ověřování certifikátů v ASP.NET Core.

Ověřování systému Windows bylo rozšířeno na Linux a macOS. V předchozích verzích bylo ověřování systému Windows omezeno na službu IIS a HTTP.sys. V systému ASP.NET Core 3.0 Kestrel má možnost používat negotiate, Kerberos a NTLM ve Windows, Linuxu a macOS pro hostitele připojené k doméně Windows. Kestrel Podpora těchto schémat ověřování je poskytována balíčkem NuGet Microsoft.AspNetCore.Authentication.Negotiate. Stejně jako u ostatních ověřovacích služeb nakonfigurujte celou ověřovací aplikaci a pak službu nakonfigurujte:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Požadavky na hostitele:

  • Hostitelé Windows musí mít přidané hlavní názvy služeb (SPN) do uživatelského účtu, který je hostitelem aplikace.
  • Počítače s Linuxem a macOS musí být připojené k doméně.
    • Hlavní názvy služeb (SPN) musí být vytvořeny pro webový proces.
    • Soubory keytab musí být generovány a nakonfigurovány na hostitelském počítači.

Další informace najdete v tématu Konfigurace ověřování systému Windows v ASP.NET Core.

Změny šablony

Šablony webového uživatelského rozhraní (Razor Stránky, MVC se kontrolerem a zobrazeními) mají následující odebrání:

Šablona Angular byla aktualizována tak, aby používala Angular 8.

Šablona Razor knihovny tříd (RCL) ve výchozím nastavení umožňuje Razor vývoj komponent. Nová možnost šablony v sadě Visual Studio poskytuje podporu šablon pro stránky a zobrazení. Při vytváření seznamu RCL ze šablony v příkazovém prostředí předejte --support-pages-and-views možnost (dotnet new razorclasslib --support-pages-and-views).

Obecný hostitel

Šablony ASP.NET Core 3.0 používají v ASP.NET Core obecný hostitel .NET. Použité předchozí verze WebHostBuilder. Použití obecného hostitele .NET Core (HostBuilder) poskytuje lepší integraci aplikací ASP.NET Core s jinými scénáři serveru, které nejsou specifické pro web. Další informace naleznete v tématu HostBuilder nahrazení WebHostBuilder.

Konfigurace hostitele

Před vydáním ASP.NET Core 3.0 byly proměnné prostředí s předponou načteny ASPNETCORE_ pro konfiguraci hostitele webového hostitele. Ve verzi 3.0 AddEnvironmentVariables se používá k načtení proměnných prostředí s předponou DOTNET_ pro konfiguraci hostitele s CreateDefaultBuilder.

Změny injektáže konstruktoru po spuštění

Obecný hostitel podporuje pouze následující typy injektáže Startup konstruktoru:

Všechny služby se stále dají do metody vloženého přímo jako argumenty Startup.Configure . Další informace naleznete v tématu Generic Host restricts Startup constructor injection (aspnet/Announcements #353).

Kestrel

  • Kestrel konfigurace byla aktualizována pro migraci na obecného hostitele. Ve verzi 3.0 Kestrel je nakonfigurován v tvůrci webových hostitelů, který ConfigureWebHostDefaultsposkytuje .
  • Připojení ion Adaptéry byly odebrány Kestrel a nahrazeny middlewarem Připojení ion, který se podobá middlewaru HTTP v kanálu ASP.NET Core, ale pro připojení nižší úrovně.
  • Transportní Kestrel vrstva byla zpřístupněna jako veřejné rozhraní v Connections.Abstractions.
  • Nejednoznačnost mezi záhlavími a přívěsy byla vyřešena přesunutím koncových hlaviček do nové kolekce.
  • Synchronní rozhraní API vstupně-výstupních operací, jako HttpRequest.Body.Readje například , jsou běžným zdrojem hladovění vláken, což vede k chybovému ukončení aplikace. Ve verzi 3.0 AllowSynchronousIO je ve výchozím nastavení zakázaná.

Další informace najdete v tématu Migrace z ASP.NET Core 2.2 na verzi 3.0.

Ve výchozím nastavení je povolený protokol HTTP/2.

Protokol HTTP/2 je ve výchozím nastavení Kestrel povolený pro koncové body HTTPS. Podpora PROTOKOLU HTTP/2 pro službu IIS nebo HTTP.sys je povolena, pokud je podporována operačním systémem.

EventCounters na vyžádání

Hostování EventSource , Microsoft.AspNetCore.Hostinggeneruje následující nové EventCounter typy související s příchozími požadavky:

  • requests-per-second
  • total-requests
  • current-requests
  • failed-requests

Směrování koncového bodu

Směrování koncových bodů, které umožňuje rozhraním (například MVC) dobře pracovat s middlewarem, je vylepšená:

  • Pořadí middlewaru a koncových bodů je možné konfigurovat v kanálu zpracování požadavků .Startup.Configure
  • Koncové body a middleware se dobře skládají s dalšími technologiemi založenými na jádrech ASP.NET, jako jsou kontroly stavu.
  • Koncové body můžou implementovat zásady, jako je CORS nebo autorizace, v middlewaru i MVC.
  • Filtry a atributy lze umístit na metody v kontrolerů.

Další informace najdete v tématu Směrování v ASP.NET Core.

Kontroly stavu

Kontroly stavu používají směrování koncových bodů s obecným hostitelem. MapHealthChecks Volání Startup.Configuretvůrce koncových bodů pomocí adresy URL koncového bodu nebo relativní cesty:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHealthChecks("/health");
});

Koncové body kontroly stavu můžou:

  • Zadejte jednoho nebo více povolených hostitelů nebo portů.
  • Vyžadovat autorizaci.
  • Vyžadovat CORS.

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

Kanály v httpContext

Teď je možné přečíst tělo požadavku a zapsat text odpovědi pomocí System.IO.Pipelines rozhraní API. Tato HttpRequest.BodyReader vlastnost poskytuje PipeReader možnost, kterou lze použít ke čtení textu požadavku. Vlastnost HttpResponse.BodyWriter poskytuje PipeWriter , kterou lze použít k zápisu textu odpovědi. HttpRequest.BodyReader je analogový HttpRequest.Body proud. HttpResponse.BodyWriter je analogový HttpResponse.Body proud.

Vylepšené hlášení chyb ve službě IIS

Chyby při spuštění při hostování aplikací ASP.NET Core ve službě IIS teď vytvářejí bohatší diagnostická data. Tyto chyby se hlásí do protokolu událostí Systému Windows s trasování zásobníku, kdykoli je to možné. Kromě toho se všechna upozornění, chyby a neošetřené výjimky protokolují do protokolu událostí systému Windows.

Pracovní služba a sada SDK pracovního procesu

.NET Core 3.0 zavádí novou šablonu aplikace Služby pracovních procesů. Tato šablona poskytuje výchozí bod pro psaní dlouhotrvajících služeb v .NET Core.

Další informace naleznete v tématu:

Vylepšení middlewaru předávaných hlaviček

V předchozích verzích ASP.NET Core bylo volání UseHsts a UseHttpsRedirection problematické při nasazení do Azure Linuxu nebo za jakýmkoli jiným reverzním proxy serverem než IIS. Oprava předchozích verzí je popsaná ve schématu Předávání pro reverzní proxy servery linuxu a jiné služby než IIS.

Tento scénář je opravený v ASP.NET Core 3.0. Hostitel povolí middleware Forwarded Headers, pokud ASPNETCORE_FORWARDEDHEADERS_ENABLED je proměnná prostředí nastavena na true. ASPNETCORE_FORWARDEDHEADERS_ENABLED je nastavená na true image kontejneru.

Zlepšení výkonu

ASP.NET Core 3.0 obsahuje řadu vylepšení, která snižují využití paměti a zlepšují propustnost:

  • Snížení využití paměti při použití integrovaného kontejneru injektáže závislostí pro omezené služby
  • Snížení přidělení napříč architekturou, včetně scénářů middlewaru a směrování
  • Snížení využití paměti pro připojení WebSocket
  • Vylepšení snížení a propustnosti paměti pro připojení HTTPS.
  • Nový optimalizovaný a plně asynchronní JSserializátor ON.
  • Snížení využití paměti a vylepšení propustnosti při analýze formulářů

ASP.NET Core 3.0 běží jenom v .NET Core 3.0.

Od ASP.NET Core 3.0 už rozhraní .NET Framework není podporovanou cílovou architekturou. Projekty, které cílí na rozhraní .NET Framework, můžou pokračovat plně podporovaným způsobem pomocí verze .NET Core 2.1 LTS. Většina balíčků souvisejících s ASP.NET Core 2.1.x se bude podporovat neomezeně dlouho, a to po dobu tříletého období LTS pro .NET Core 2.1.

Informace o migraci najdete v tématu Portování kódu z rozhraní .NET Framework do .NET Core.

Použití sdílené architektury ASP.NET Core

Sdílená architektura ASP.NET Core 3.0 obsažená v metabalíku Microsoft.AspNetCore.App už nevyžaduje explicitní <PackageReference /> prvek v souboru projektu. Sdílená architektura se automaticky odkazuje při použití Microsoft.NET.Sdk.Web sady SDK v souboru projektu:

<Project Sdk="Microsoft.NET.Sdk.Web">

Sestavení odebraná ze sdílené architektury ASP.NET Core

Nejdůležitější sestavení odebraná ze sdílené architektury ASP.NET Core 3.0 jsou:

Úplný seznam sestavení odebraných ze sdílené architektury naleznete v tématu Odebrání sestavení z Microsoft.AspNetCore.App 3.0. Další informace o motivaci k této změně najdete v tématu Zásadní změny Microsoft.AspNetCore.App ve verzi 3.0 a první pohled na změny přicházející v ASP.NET Core 3.0.