Co je nového ve ASP.NET Core 3.0

  • Článek
  • 6 min ke čtení

Tento článek se týká nejvýznamnějších změn ve ASP.NET Core 3.0 s odkazy na příslušnou dokumentaci.

Blazor

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

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

Blazor podporované scénáře architektury:

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

Další informace naleznete v tématu Úvod do ASP.NET Core Blazor.

Blazor Server

Blazor oddělení logiky vykreslování komponent od způsobu použití aktualizací uživatelského rozhraní. Blazor Serverposkytuje podporu pro Razor hostování komponent na serveru v ASP.NET Core aplikaci. Aktualizace uživatelského rozhraní se zpracovávají přes SignalR připojení. Blazor Serverse podporuje ve ASP.NET Core 3.0.

Blazor WebAssembly (Preview)

Blazor Aplikace lze také spustit přímo v prohlížeči pomocí modulu runtime .NET založeného na WebAssembly. Blazor WebAssemblyje ve verzi Preview a ve verzi ASP.NET Core 3.0 se nepodporuje. Blazor WebAssemblybude podporován v budoucí verzi ASP.NET Core.

Razor Součásti

Blazor Aplikace jsou sestavené z komponent. Součásti jsou samostatné bloky uživatelského rozhraní, například stránka, dialogové okno nebo formulář. Komponenty jsou normální třídy rozhraní .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 v Blazor nástroji se obvykle vytvářely Razor pomocí syntaxe, přirozené kombinace HTML a jazyka C#. Razor Komponenty jsou podobné zobrazením Pages a Razor MVC v tom, že obě používají Razor . Na rozdíl od stránek a zobrazení, které jsou založené na modelu požadavku a odpovědi, se komponenty používají speciálně pro zpracování složení uživatelského rozhraní.

gRPC

gRPC:

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

  • Nabízí názorný přístup k vývoji rozhraní API založený na kontraktu.

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

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

  • Poskytuje například tyto funkce:

    • Authentication
    • Obousměrné streamování a řízení toku.
    • Zrušení a časové limity.

Funkce gRPC ve ASP.NET Core 3.0 zahrnuje:

  • Grpc.AspNetCore:ASP.NET Core rozhraní 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 HttpClient rozhraní .
  • Grpc.Net.ClientFactory:integrace klienta gRPC s HttpClientFactory .

Další informace naleznete v tématu Úvod do gRPC v .NET.

SignalR

Pokyny k migraci najdete SignalR v tématu Aktualizace kódu. SignalR teď používá System.Text.Json k serializaci/deserializaci zpráv JSON. Pokyny k obnovení serializátoru založeného na Newtonsoft.Jsnajdete v tématu Přepnutí na Newtonsoft.JsNewtonsoft.Json on.

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

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í na základě milisekund:

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

Vlastní implementaci lze předat pro úplnou kontrolu nad intervaly 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 o opětovné připojení.

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

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

  • onreconnecting: Dává vývojářům příležitost zakázat uživatelské rozhraní nebo uživatelům povolit, aby věděli, že je aplikace offline.
  • onreconnected: Dává vývojářům příležitost aktualizovat uživatelské rozhraní, jakmile se připojení znovu načtou.

Následující kód používá k onreconnecting 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á k onreconnected 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 Verze 3.0 a novější poskytuje vlastní prostředek pro obslužné rutiny autorizace, když metoda centra vyžaduje autorizaci. Prostředek je instance HubInvocationContext . HubInvocationContextobsahuje:

  • HubCallerContext
  • Název vyvolané metody centra.
  • Argumenty metody centra.

Představte si následující příklad aplikace chatovací místnosti umožňující přihlášení více organizací přes Azure Active Directory. Každý, kdo účet Microsoft se může přihlásit k chatu, ale jenom členové vlastnící organizace mohou zakázat uživatele nebo zobrazit historii chatu 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 slouží DomainRestrictedRequirement jako vlastní IAuthorizationRequirement . Vzhledem k HubInvocationContext tomu, že se předává parametr prostředku, může interní logika:

  • Zkontrolujte kontext, ve kterém se volá centrum.
  • 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ásad, které kód kontroluje za běhu. Když se klienti pokoušejí volat jednotlivé metody centra, obslužná rutina spustí a DomainRestrictedRequirement řídí přístup k metodám. Na základě způsobu, jakým DomainRestrictedRequirement řídí přístup:

  • Všichni přihlášení uživatelé mohou volat SendMessage metodu .
  • Jenom uživatelé, kteří se přihlásili pomocí @jabbr.net e-mailové adresy, mohou zobrazit historii uživatelů.
  • Z bob42@jabbr.net chatovací místnosti používejte jen zákaz uživatelů.
[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

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

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

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

  • V souboru Startup.cs přidejte novou zásadu.
  • Zadejte vlastní DomainRestrictedRequirement požadavek jako parametr.
  • Registrace DomainRestricted pomocí autorizačního middlewaru
services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalRCentra používají směrování koncových bodů. SignalR připojení k centru bylo dříve provedeno explicitně:

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

V předchozí verzi potřebovali vývojáři na různých místech za provozu Razor kontrolery, stránky a rozbočovače. Explicitní připojení má za výsledek řadu 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 přes směrování koncového bodu. Se směrováním koncového bodu je obvykle možné nakonfigurovat veškeré směrování UseRouting v :

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

ASP.NET Core 3.0: SignalR

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

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

Klientské aplikace .NET mohou jako argument výše uvedené metody centra předat instanci nebo IAsyncEnumerable<T> ChannelReader<T> stream UploadStream .

Po dokončení smyčky a ukončení místní funkce se odesílá for dokončení streamu:

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 používají jako argument výše uvedené metody Centra objekt (nebo předmět SignalR Subject RxJS). stream UploadStream

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

Kód Jazyka JavaScript může pomocí metody zpracovávat řetězce, které jsou zachyceny a připraveny k odeslání subject.next 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í pro streamování v reálném čase.

Nová serializace JSON

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

  • Čte a zapisuje JSON asynchronně.
  • Je optimalizovaný pro text UTF-8.
  • Obvykle vyšší výkon než Newtonsoft.Json .

Pokud chcete Json.NET do ASP.NET Core 3.0, podívejte se na Newtonsoft.Jspodpory pro přidání formátu JSON založeného na systému.

Nové Razor direktivy

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

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

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

ASP.NET Core 3.0 nabízí ověřování v jedno stránkách aplikací (SPA) s využitím podpory pro autorizaci webového rozhraní API. ASP.NET Core Identitypro ověřování a ukládání uživatelů se kombinuje se Identity Serverem 4 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í /off (SSO) u více typů aplikací
  • Řízení přístupu pro rozhraní API
  • Brána FS (Federation Gateway)

Další informace najdete v dokumentaci Identity k Serveru 4 nebo v tématu Ověřování a autorizace pro spa.

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 v Startup.Configure .
  • Přidání ověřovací služby certifikátů v 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ří:

  • Přijměte certifikáty podepsané svým držitelem.
  • Zkontrolujte odvolání certifikátu.
  • Zkontrolujte, že pronabídovaný certifikát obsahuje 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 naleznete v tématu Konfigurace ověřování certifikátů v ASP.NET Core.

Windows ověřování se rozšířilo na Linux a macOS. V předchozích verzích bylo Windows ověřování omezeno na IIS aHTTP.sys. Ve ASP.NET Core 3.0 má možnost používat negotiate, kerberos a NTLM v Kestrel systémech Windows,Linux a macOS pro Windows hostitelů připojených k doméně. KestrelPodpora 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 ověřovací aplikaci v celé šířce a pak nakonfigurujte službu:

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:

  • Windows hostitelé musí mít přidané hlavní názvy služby (SPN) do uživatelského účtu hostujícího aplikaci.
  • Počítače s Linuxem a macOS musí být připojené k doméně.
    • Hlavní název služby (SPN) musí být vytvořený pro webový proces.
    • Na hostitelském počítači musí být vygenerovány a nakonfigurovány soubory keytab.

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

Změny šablon

Z šablon webového uživatelského rozhraní ( Stránky, MVC s kontroleru a Razor zobrazeními) se odebraly tyto položky:

  • Uživatelské cookie rozhraní pro udělení souhlasu už není zahrnuté. Pokud chcete funkci cookie souhlasu povolit v aplikaci vygenerované šablonou ASP.NET Core 3.0, podívejte se na . Obecné nařízení o ochraně osobních údajů (GDPR) v ASP.NET Core
  • Skripty a související statické prostředky se teď místo používání sítí CDN odkazují jako na místní soubory. Další informace najdete v tématu Skripty a související statické prostředky se teď odkazují jako na místní soubory místo používání sítí CDN na základě aktuálního prostředí (dotnet/AspNetCore.Docs #14350).

Šablona Angular byla aktualizována tak, aby Angular 8.

Šablona Razor knihovny tříd (RCL) ve výchozím nastavení využívá Razor vývoj komponent. Nová možnost šablony v 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í Obecný hostitel .NET v ASP.NET Core . Předchozí verze používaly WebHostBuilder . Použití obecného hostitele .NET Core ( ) poskytuje lepší integraci aplikací ASP.NET Core s jinými scénáři serveru, které nejsou specifické HostBuilder pro web. Další informace najdete v tématu HostBuilder nahrazuje WebHostBuilder.

Konfigurace hostitele

Před vydáním verze ASP.NET Core 3.0 byly načteny proměnné prostředí s předponou pro konfiguraci hostitele ASPNETCORE_ webového hostitele. Ve windows 3.0 se pro konfiguraci hostitele s načítá proměnné prostředí s AddEnvironmentVariables DOTNET_ předponou CreateDefaultBuilder .

Změny injektáže spouštěcího konstruktoru

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

Všechny služby lze stále přímo vloženého jako argumenty do Startup.Configure metody. Další informace najdete v tématu Obecný hostitel omezuje injektáž konstruktoru spouštění (aspnet/Announcements #353).

Kestrel

  • Kestrel konfigurace byla aktualizována pro migraci na obecného hostitele. Ve službě 3.0 se Kestrel konfiguruje ve tvůrci webového hostitele, který poskytuje ConfigureWebHostDefaults .
  • Adaptéry připojení byly odebrány z middlewaru připojení a nahrazeny middlewarem připojení, který se podobá middlewaru HTTP v kanálu ASP.NET Core, ale u připojení Kestrel nižší úrovně.
  • Přenosová Kestrel vrstva byla zveřejněna jako veřejné rozhraní v Connections.Abstractions .
  • Nejednoznačnost mezi hlavičkami a koncovími hlavičkami byla vyřešena přesunutím koncových hlaviček do nové kolekce.
  • Synchronní vstupně-výstupní rozhraní API, jako je , jsou běžným zdrojem pro propadení vláken, což vede HttpRequest.Body.Read k selhání aplikace. Ve windows 3.0 AllowSynchronousIO je ve výchozím nastavení zakázaný.

Další informace naleznete v tématu migrace z ASP.NET Core 2,2 na 3,0.

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

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

EventCounters on request

EventSource hostování Microsoft.AspNetCore.Hosting vysílá 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

Vylepšené je směrování koncových bodů, které umožňuje, aby architektury (například MVC) dobře fungovaly s middlewarem:

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

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

Kontroly stavu

Kontroly stavu používají směrování koncového bodu s obecným hostitelem. V Startup.Configure volejte MapHealthChecks u tvůrce koncových bodů s adresou URL koncového bodu nebo relativní cestou:

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

Koncové body kontroly stavu mohou:

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

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

Kanály v objektu HttpContext

Teď je možné přečíst text požadavku a napsat text odpovědi pomocí rozhraní System.IO.Pipelines API. Prostředek HttpRequest.BodyReader vlastnost poskytuje PipeReader objekt , který lze použít ke čtení textu požadavku. Prostředek HttpResponse.BodyWriter vlastnost poskytuje PipeWriter objekt , který lze použít k zápisu textu odpovědi. HttpRequest.BodyReader je obdobou HttpRequest.Body datového proudu. HttpResponse.BodyWriter je obdobou HttpResponse.Body datového proudu.

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

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

Sada SDK služby pracovních procesů a pracovních procesů

.NET Core 3.0 zavádí novou šablonu aplikace služby pracovního procesu. Tato šablona poskytuje výchozí bod pro zápis dlouhotrvacích služeb v .NET Core.

Další informace naleznete v tématu:

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

V předchozích verzích ASP.NET Core byly volání a problematické při nasazení do Azure Linuxu nebo za jiným reverzním UseHsts UseHttpsRedirection proxy serverem než IIS. Oprava předchozích verzí je zdokumentovaná v článku Přesměrování schématu pro Linux a reverzní servery pro jiné servery než IIS.

Tento scénář je opravený ve ASP.NET Core 3.0. Pokud je proměnná prostředí nastavená na hodnotu , hostitel povolí middleware předáovaných ASPNETCORE_FORWARDEDHEADERS_ENABLED true hlaviček. ASPNETCORE_FORWARDEDHEADERS_ENABLED je v našich true imagí kontejneru nastavená na .

Vylepšení výkonu

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

  • Snížení využití paměti při použití integrovaného kontejneru injektáže závislostí pro vymezené 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í paměti a propustnosti pro připojení HTTPS.
  • Nový optimalizovaný a plně asynchronní serializátor JSON.
  • Snížení využití paměti a vylepšení propustnosti při analýze formulářů.

ASP.NET Core verze 3.0 běží jenom na .NET Core 3.0.

Od ASP.NET Core verze 3.0 .NET Framework už není podporovanou cílovou architekturou. Projekty cílené .NET Framework mohou pokračovat plně podporovaným způsobem pomocí verze .NET Core 2.1 LTS. Většina ASP.NET Core 2.1.x se bude podporovat po dobu tří let pro .NET Core 2.1.

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

Použití ASP.NET Core architektury

Rozhraní ASP.NET Core 3.0 obsažené v Microsoft.AspNetCore.App metabalíkuuž nevyžaduje explicitní <PackageReference /> prvek v souboru projektu. Při použití sady SDK v souboru projektu se automaticky odkazuje na Microsoft.NET.Sdk.Web sdílenou rozhraní:

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

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

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

Úplný seznam sestavení odebraných ze sdílené architektury najdete v tématu Sestavení odebraná z Microsoft.AspNetCore.App 3.0. Další informace o motivaci pro tuto změnu najdete v článku o rozbíjení změn v systému Microsoft.AspNetCore.App ve 3.0 a První pohled na změny, které přicházejí v ASP.NET Core 3.0.