Migrace z ASP.NET Core 2.2 na verzi 3.0

Scott Addie a Rick Anderson

Tento článek vysvětluje, jak aktualizovat existující projekt ASP.NET Core 2.2 na ASP.NET Core 3.0. Může být užitečné vytvořit nový projekt ASP.NET Core 3.0 pro:

• Porovnejte s kódem ASP.NET Core 2.2.
• Zkopírujte relevantní změny do projektu ASP.NET Core 3.0.

Požadavky

Aktualizace verze sady .NET Core SDK v global.json

Pokud vaše řešení spoléhá na global.json soubor, který cílí na konkrétní verzi sady .NET Core SDK, aktualizujte jeho version vlastnost na verzi 3.0 nainstalovanou na vašem počítači:

{
  "sdk": {
    "version": "3.0.100"
  }
}

Aktualizace souboru projektu

Aktualizace cílové architektury

ASP.NET Core 3.0 a novější běží jenom v .NET Core. Nastavte moniker cílové architektury (TFM) na netcoreapp3.0:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

Odebrání zastaralých odkazů na balíčky

Pro ASP.NET Core 3.0 se nevygeneruje velký počet balíčků NuGet. Tyto odkazy na balíčky by se měly odebrat ze souboru projektu. Zvažte následující soubor projektu pro webovou aplikaci ASP.NET Core 2.2:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App"/>
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
  </ItemGroup>

</Project>

Aktualizovaný soubor projektu pro ASP.NET Core 3.0:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

Aktualizovaný soubor projektu ASP.NET Core 3.0:

• V :<PropertyGroup>

  • Aktualizuje TFM na netcoreapp3.0
  • Odebere <AspNetCoreHostingModel> prvek. Další informace najdete v tématu Model hostování v procesu v tomto dokumentu.

• V :<ItemGroup>

  • Microsoft.AspNetCore.App je odebrán. Další informace naleznete v tématu Framework reference v tomto dokumentu.
  • Microsoft.AspNetCore.Razor.Design se odebere a v následujícím seznamu balíčků se už nevytvájí.

Pokud chcete zobrazit úplný seznam balíčků, které se už nevytvůrují, vyberte následující seznam rozbalení:

Kontrola zásadních změn

Kontrola zásadních změn

Referenční informace k rozhraní

Funkce ASP.NET Core, které byly dostupné prostřednictvím některého z výše uvedených balíčků, jsou k dispozici jako součást Microsoft.AspNetCore.App sdílené architektury. Sdílená architektura je sada sestavení (.dll souborů), která jsou nainstalovaná na počítači a obsahuje komponentu modulu runtime a sadu cílení. Další informace naleznete v části Sdílená architektura.

• Projekty, které cílí na Microsoft.NET.Sdk.Web sadu SDK, implicitně odkazují na architekturu Microsoft.AspNetCore.App .

  Pro tyto projekty nejsou vyžadovány žádné další odkazy:

  <Project Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
      <TargetFramework>netcoreapp3.0</TargetFramework>
    </PropertyGroup>
      ...
  </Project>
  

• Projekty, které cílí Microsoft.NET.Sdk nebo Microsoft.NET.Sdk.Razor sada SDK, by měly přidat explicitníFrameworkReference:Microsoft.AspNetCore.App

  <Project Sdk="Microsoft.NET.Sdk.Razor">
    <PropertyGroup>
      <TargetFramework>netcoreapp3.0</TargetFramework>
    </PropertyGroup>
  
    <ItemGroup>
      <FrameworkReference Include="Microsoft.AspNetCore.App" />
    </ItemGroup>
      ...
  </Project>
  

Sestavení závislá na rozhraní pomocí Dockeru

Sestavení konzolových aplikací závislých na architektuře, které používají balíček, který závisí na sdílené architektuře ASP.NET Core, může obsahovat následující chybu za běhu:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found.
  - No frameworks were found.

Microsoft.AspNetCore.App je sdílená architektura obsahující modul runtime ASP.NET Core a nachází se pouze v imagi Dockeru dotnet/core/aspnet . Sada SDK 3.0 zmenšuje velikost sestavení závislých na rozhraní využívajících ASP.NET Core tím, že nezahrnuje duplicitní kopie knihoven, které jsou dostupné ve sdíleném rozhraní. To je potenciální úspora až 18 MB, ale vyžaduje, aby se aplikace spustila ASP.NET core runtime nebo nainstalovaná.

Pokud chcete zjistit, jestli má aplikace závislost (přímou nebo nepřímou) na sdílené rozhraní ASP.NET Core, prozkoumejte runtimeconfig.json soubor vygenerovaný během sestavení nebo publikování aplikace. Následující soubor JSON ukazuje závislost na sdílené rozhraní ASP.NET Core:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.AspNetCore.App",
      "version": "3.0.0"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

Pokud vaše aplikace používá Docker, použijte základní image, která zahrnuje ASP.NET Core 3.0. Například docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0.

Přidání odkazů na balíčky pro odebraná sestavení

ASP.NET Core 3.0 odebere některá sestavení, která byla dříve součástí odkazu na Microsoft.AspNetCore.App balíček. Pokud chcete vizualizovat, která sestavení byla odebrána, porovnejte dvě složky se sdílenou architekturou. Například porovnání verzí 2.2.7 a 3.0.0:

Pokud chcete pokračovat v používání funkcí poskytovaných odebranými sestaveními, odkazujte na verze 3.0 odpovídajících balíčků:

• Webová aplikace generovaná šablonou s individuálními uživatelskými účty vyžaduje přidání následujících balíčků:

  <Project Sdk="Microsoft.NET.Sdk.Web">
  
    <PropertyGroup>
      <TargetFramework>netcoreapp3.0</TargetFramework>
      <UserSecretsId>My-secret</UserSecretsId>
    </PropertyGroup>
  
    <ItemGroup>
      <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="3.0.0" />
      <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="3.0.0" />
      <PackageReference Include="Microsoft.AspNetCore.Identity.UI" Version="3.0.0" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.0.0" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="3.0.0" />
    </ItemGroup>
  
  </Project>
  

• Microsoft.EntityFrameworkCore

  Další informace o odkazování na balíček konkrétního zprostředkovatele databáze naleznete v tématu Zprostředkovatelé databáze.

• Identity UI

  Podporu uživatelského Identity rozhraní můžete přidat odkazem na Microsoft.AspNetCore.Identity. Balíček uživatelského rozhraní .

• SPA Services

  • Microsoft.AspNetCore.SpaServices
  • Microsoft.AspNetCore.SpaServices.Extensions

• Ověřování: Podpora toků ověřování třetích stran je k dispozici jako balíčky NuGet:

  • Facebook OAuth (Microsoft.AspNetCore.Authentication.Facebook)
  • Google OAuth (Microsoft.AspNetCore.Authentication.Google)
  • Ověřování účtu Microsoft (Microsoft.AspNetCore.Authentication.MicrosoftAccount)
  • Ověřování OpenID Connect (Microsoft.AspNetCore.Authentication.OpenIdConnect)
  • Nosný token OpenID Connect (Microsoft.AspNetCore.Authentication.JwtBearer)
  • Twitter OAuth (Microsoft.AspNetCore.Authentication.Twitter)
  • Ověřování WsFederation (Microsoft.AspNetCore.Authentication.WsFederation)

• Podpora formátování a vyjednávání obsahu pro : Balíček NuGet Microsoft.AspNet.WebApi.Client poskytuje užitečnou rozšiřitelnost System.Net.HttpClient pro rozhraní API, jako ReadAsAsync je například a PostJsonAsync.System.Net.HttpClient Tento balíček však závisí na Newtonsoft.Json, ne System.Text.Json. To znamená, že například názvy serializace vlastnosti určené (JsonPropertyNameAttributeSystem.Text.Json) jsou ignorovány. Existuje novější balíček NuGet, který obsahuje podobné rozšiřující metody, ale používá System.Text.Json: System.Net.Http.Json.

• Razor kompilace modulu runtime: Podpora kompilace Razor zobrazení a stránek za běhu je nyní součástí Microsoft.AspNetCore.Mvc.Razor. RuntimeCompilation.

• Podpora MVC Newtonsoft.Json (Json.NET): Podpora použití MVC s Newtonsoft.Json je nyní součástí Microsoft.AspNetCore.Mvc.NewtonsoftJsonprogramu .

Změny při spuštění

Následující obrázek ukazuje odstraněné a změněné řádky ve webové aplikaci ASP.NET Core 2.2 Razor Pages:

Na předchozím obrázku se odstraněný kód zobrazuje červeně. Odstraněný kód nezobrazuje cookie kód možností, který byl odstraněn před porovnáním souborů.

Následující obrázek ukazuje přidané a změněné řádky ve webové aplikaci ASP.NET Core 3.0 Razor Pages:

Na předchozím obrázku se přidaný kód zobrazuje zeleně. Informace o následujících změnách:

• services.AddMvcviz services.AddRazorPagesregistrace služby MVC v tomto dokumentu.
• CompatibilityVersion, viz Verze kompatibility pro ASP.NET Core MVC.
• IHostingEnvironmenta podívejte se na IWebHostEnvironmenttoto oznámení GitHubu.
• app.UseAuthorization byla přidána do šablon, aby bylo možné zobrazit middleware pro autorizaci objednávek. Pokud aplikace nepoužívá autorizaci, můžete hovor app.UseAuthorizationbezpečně odebrat .
• app.UseEndpoints, viz Razor Stránky nebo Migrovat startup.Configure v tomto dokumentu.

Podpora analyzátoru

Projekty, které cílí Microsoft.NET.Sdk.Web na implicitně referenční analyzátory dříve dodávané jako součást balíčku Microsoft.AspNetCore.Mvc.Analyzers . K jejich povolení nejsou potřeba žádné další odkazy.

Pokud vaše aplikace používá dříve dodané analyzátory rozhraní API pomocí balíčku Microsoft.AspNetCore.Mvc.Api.Analyzers, upravte soubor projektu tak, aby odkazoval na analyzátory dodané jako součást webové sady SDK .NET Core:

<Project Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <IncludeOpenAPIAnalyzers>true</IncludeOpenAPIAnalyzers>
    </PropertyGroup>

    ...
</Project>

Razor knihovna tříd

Razor Projekty knihovny tříd, které poskytují součásti uživatelského rozhraní pro MVC, musí nastavit AddRazorSupportForMvc vlastnost v souboru projektu:

<PropertyGroup>
  <AddRazorSupportForMvc>true</AddRazorSupportForMvc>
</PropertyGroup>

Model vnitroprocesového hostování

Projekty ve výchozím nastavení využívají model hostování v procesu ve verzi ASP.NET Core 3.0 nebo novější. Volitelně můžete vlastnost v souboru projektu odebrat <AspNetCoreHostingModel> , pokud je InProcessjejí hodnota .

Kestrel

Konfigurace

Migrace Kestrel konfigurace do tvůrce webového hostitele poskytovaného ConfigureWebHostDefaults (Program.cs):

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureKestrel(serverOptions =>
            {
                // Set properties and call methods on options
            })
            .UseStartup<Startup>();
        });

Pokud aplikace místo toho vytvoří hostitele ručně ConfigureWebHost ConfigureWebHostDefaults, zavolejte UseKestrel tvůrce webových hostitelů:

public static void Main(string[] args)
{
    var host = new HostBuilder()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .ConfigureWebHost(webBuilder =>
        {
            webBuilder.UseKestrel(serverOptions =>
            {
                // Set properties and call methods on options
            })
            .UseIISIntegration()
            .UseStartup<Startup>();
        })
        .Build();

    host.Run();
}

Middleware připojení nahrazuje adaptéry připojení.

Adaptéry připojení (Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter) byly odebrány z Kestrelaplikace . Adaptéry připojení nahraďte middlewarem připojení. Middleware připojení se podobá middlewaru HTTP v kanálu ASP.NET Core, ale pro připojení nižší úrovně. Protokolování https a připojení:

• Byly přesunuty z adaptérů připojení do middlewaru připojení.
• Tyto metody rozšíření fungují stejně jako v předchozích verzích ASP.NET Core.

Další informace najdete v příkladu TlsFilterConnectionHandler v části ListenOptions.Protocols článkuKestrel.

Dopravní abstrakce přesunuté a zpřístupněné veřejnosti

Transportní Kestrel vrstva byla zpřístupněna jako veřejné rozhraní v Connections.Abstractions. V rámci těchto aktualizací:

• Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions a přidružené typy byly odebrány.
• NoDelay byla přesunuta z ListenOptions možností dopravy.
• Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.Internal.SchedulingMode byla odebrána z KestrelServerOptions.

Další informace najdete v následujících zdrojích informací na GitHubu:

• Abstrakce sítí klienta/serveru (dotnet/AspNetCore #10308)
• Implementace nové abstrakce naslouchacího procesu naslouchacího kola a opětovného platu Kestrel (dotnet/AspNetCore #10321)

Kestrel Hlavičky žádosti o přívěs

Pro aplikace, které cílí na starší verze ASP.NET Core:

• Kestrel přidá hlavičky blokovaných přívěsů HTTP/1.1 do kolekce hlaviček požadavků.
• Přívěsy jsou k dispozici po přečtení textu požadavku na konec.

To způsobuje určité obavy ohledně nejednoznačnosti mezi hlavičkami a přívěsy, takže přívěsy byly přesunuty do nové kolekce (RequestTrailerExtensions) ve verzi 3.0.

Požadavky HTTP/2 jsou:

• V ASP.NET Core 2.2 není k dispozici.
• K dispozici ve verzi 3.0 jako RequestTrailerExtensions.

Pro přístup k těmto přívěsům jsou k dispozici nové metody rozšíření požadavků. Stejně jako u HTTP/1.1 jsou přívěsy k dispozici po přečtení textu požadavku na konec.

Pro verzi 3.0 jsou k dispozici následující RequestTrailerExtensions metody:

• GetDeclaredTrailers: Získá hlavičku požadavku Trailer , která uvádí, které přívěsy mají očekávat po těle.
• SupportsTrailers: Určuje, zda žádost podporuje příjem hlaviček přívěsu.
• CheckTrailersAvailable: Zkontroluje, jestli žádost podporuje přívěsy a zda jsou k dispozici ke čtení. Tato kontrola nepředpokládá, že existují přívěsy ke čtení. Tato metoda nemusí číst žádné přívěsy, i když true je vrácena touto metodou.
• GetTrailer: Získá požadovanou koncovou hlavičku z odpovědi. Před voláním GetTrailerNotSupportedException zkontrolujte SupportsTrailers nebo může dojít, pokud požadavek nepodporuje koncové hlavičky.

Další informace naleznete v tématu Put request trailers in a separate collection (dotnet/AspNetCore #10410).

AllowSynchronousIO disabled

AllowSynchronousIO povolí nebo zakáže synchronní rozhraní API vstupně-výstupních operací, například HttpRequest.Body.Read, HttpResponse.Body.Writea Stream.Flush. Tato rozhraní API jsou 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 části Synchronní vstupně-výstupní operace v Kestrel článku.

Pokud je potřeba synchronní vstupně-výstupní operace, můžete ji povolit konfigurací AllowSynchronousIO možnosti na používaném serveru (například při volání ConfigureKestrel).Kestrel Všimněte si, že všechny servery (KestrelHttpSys, TestServer atd.) mají vlastní AllowSynchronousIO možnost, která nebude mít vliv na ostatní servery. Synchronní vstupně-výstupní operace je možné povolit pro všechny servery na základě požadavku pomocí této IHttpBodyControlFeature.AllowSynchronousIO možnosti:

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();

if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

Pokud máte potíže s TextWriter implementacemi nebo jinými datovými proudy, které volají synchronní rozhraní API v Dispose, zavolejte místo toho nové DisposeAsync rozhraní API.

Další informace naleznete v tématu [Oznámení] AllowSynchronousIO zakázáno na všech serverech (dotnet/AspNetCore #7644).

Ukládání výstupních formátovačů do vyrovnávací paměti

Newtonsoft.JsonXmlSerializer a DataContractSerializer formátovací moduly založené na výstupech podporují pouze synchronní serializaci. Aby tyto formátovací moduly fungovaly s omezeními AllowSynchronousIO serveru, MVC před zápisem na disk zasadí výstup těchto formátování do vyrovnávací paměti. V důsledku ukládání do vyrovnávací paměti bude MVC obsahovat hlavičku Content-Length při odpovídání pomocí těchto formátovacích metod.

System.Text.Json podporuje asynchronní serializaci a v důsledku toho System.Text.Json formátovací modul neukládá vyrovnávací paměť. Zvažte použití tohoto formátovače pro lepší výkon.

Pokud chcete zakázat ukládání do vyrovnávací paměti, můžou aplikace nakonfigurovat SuppressOutputFormatterBuffering při spuštění:

services.AddControllers(options => options.SuppressOutputFormatterBuffering = true)

Upozorňujeme, že to může způsobit, že aplikace vyvolá výjimku za běhu, pokud AllowSynchronousIO není také nakonfigurovaná.

Microsoft.AspNetCore.Server.Kestrel. Odebrání sestavení HTTPS

V ASP.NET Core 2.1 obsah Microsoft.AspNetCore.Server.Kestrel. Https.dll byly přesunuty na Microsoft.AspNetCore.Server.Kestrel. Core.dll. Jednalo se o nerušnou aktualizaci pomocí TypeForwardedTo atributů. Pro verzi 3.0 je prázdný Microsoft.AspNetCore.Server.Kestrel. Https.dll sestavení a balíček NuGet byly odebrány.

Knihovny odkazující na Microsoft.AspNetCore.Server.Kestrel. Protokol HTTPS by měl aktualizovat ASP.NET základní závislosti na verzi 2.1 nebo novější.

Aplikace a knihovny cílené na ASP.NET Core 2.1 nebo novější by měly odebrat všechny přímé odkazy na Microsoft.AspNetCore.Server.Kestrel. Balíček HTTPS .

Podpora Newtonsoft.Json (Json.NET)

V rámci práce na vylepšení sdílené architektury ASP.NET Core byla z sdílené architektury ASP.NET Core odebrána nová architektura Newtonsoft.Json (Json.NET).

Výchozí serializátor JSON pro ASP.NET Core je teď System.Text.Jsonnový v .NET Core 3.0. Zvažte použití System.Text.Json , pokud je to možné. Je vysoce výkonný a nevyžaduje další závislost knihovny. Vzhledem k tomu, že System.Text.Json je nová, může v současné době chybět funkce, které vaše aplikace potřebuje. Další informace najdete v tématu Jak migrovat z Newtonsoft.Json na System.Text.Json.

Použití Newtonsoft.Json v projektu ASP.NET Core 3.0 SignalR

• Nainstalujte Microsoft.AspNetCore.SignalR. Balíček Protocols.NewtonsoftJson NuGet.

• V klientovi zřetězte AddNewtonsoftJsonProtocol volání metody do HubConnectionBuilder instance:

  new HubConnectionBuilder()
      .WithUrl("/chathub")
      .AddNewtonsoftJsonProtocol(...)
      .Build();
  

• Na serveru zřetězte AddNewtonsoftJsonProtocol volání metody do AddSignalR volání metody v Startup.ConfigureServices:

  services.AddSignalR()
      .AddNewtonsoftJsonProtocol(...);
  

Použití Newtonsoft.Json v projektu ASP.NET Core 3.0 MVC

• Nainstalujte balíček Microsoft.AspNetCore.Mvc.NewtonsoftJson.

• Aktualizujte Startup.ConfigureServices hovor AddNewtonsoftJson.

  services.AddMvc()
      .AddNewtonsoftJson();
  

  AddNewtonsoftJson je kompatibilní s novými metodami registrace služby MVC:

  • AddRazorPages
  • AddControllersWithViews
  • AddControllers

  services.AddControllers()
      .AddNewtonsoftJson();
  

  Newtonsoft.Json nastavení lze nastavit při volání na AddNewtonsoftJson:

  services.AddMvc()
      .AddNewtonsoftJson(options =>
             options.SerializerSettings.ContractResolver =
                new CamelCasePropertyNamesContractResolver());
  

  Poznámka: Pokud AddNewtonsoftJson tato metoda není dostupná, ujistěte se, že jste balíček nainstalovali Microsoft.AspNetCore.Mvc.NewtonsoftJson . Běžnou chybou je instalace balíčku Newtonsoft.Json místo Microsoft.AspNetCore.Mvc.NewtonsoftJson balíčku.

Další informace najdete v tématu Přidání podpory formátu JSON založeného na Newtonsoft.Json.

Registrace služby MVC

ASP.NET Core 3.0 přidává nové možnosti registrace scénářů MVC uvnitř Startup.ConfigureServices.

K dispozici jsou tři nové metody rozšíření nejvyšší úrovně související se scénáři IServiceCollection MVC. Šablony používají tyto nové metody místo AddMvc. AddMvc I nadále se ale chová stejně jako v předchozích verzích.

Následující příklad přidá podporu pro kontrolery a funkce související s rozhraním API, ale ne zobrazení nebo stránky. Šablona rozhraní API používá tento kód:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
}

Následující příklad přidá podporu pro kontrolery, funkce související s rozhraním API a zobrazení, ale ne stránky. Šablona webové aplikace (MVC) používá tento kód:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
}

Následující příklad přidá podporu pro Razor Pages a minimální podporu kontroleru. Šablona webové aplikace používá tento kód:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
}

Nové metody lze také kombinovat. Následující příklad je ekvivalentní volání AddMvc v ASP.NET Core 2.2:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddRazorPages();
}

Směrování spouštěcího kódu

Pokud aplikace volá UseMvc nebo UseSignalRpokud je to možné, migrujte aplikaci na směrování koncových bodů. Abychom vylepšili kompatibilitu směrování koncových bodů s předchozími verzemi MVC, vrátili jsme některé změny v generování adres URL zavedených v ASP.NET Core 2.2. Pokud došlo k problémům se směrováním koncových bodů ve verzi 2.2, počítejte s vylepšeními v ASP.NET Core 3.0 s následujícími výjimkami:

• Pokud aplikace implementuje IRouter nebo dědí z Route, použijte dynamicRouteValuesTransformer jako náhradu.
• Pokud aplikace přistupuje přímo do RouteData.Routers MVC k analýze adres URL, můžete ji nahradit použitím LinkParser.ParsePathByEndpointName.
  • Definujte trasu s názvem trasy.
  • Použijte LinkParser.ParsePathByEndpointName a předejte název požadované trasy.

Směrování koncových bodů podporuje stejnou syntaxi vzoru tras a funkce vytváření vzorů tras jako IRouter. Směrování koncových bodů podporuje IRouteConstraint. Směrování koncového bodu podporuje [Route][HttpGet]a další atributy směrování MVC.

U většiny aplikací vyžaduje jenom Startup změny.

Migrace po spuštění.Configure

Obecné rady:

• Přidat UseRouting.

• Pokud aplikace volá UseStaticFiles, umístěte UseStaticFiles ho před UseRouting.

• Pokud aplikace používá funkce ověřování/autorizace, jako AuthorizePage je nebo [Authorize], zavolat UseAuthentication a UseAuthorization: za a UseRouting UseCors, ale před UseEndpoints:

  public void Configure(IApplicationBuilder app)
  {
    ...
  
    app.UseStaticFiles();
  
    app.UseRouting();
    app.UseCors();
  
    app.UseAuthentication();
    app.UseAuthorization();
  
    app.UseEndpoints(endpoints => {
       endpoints.MapControllers();
    });
  

• Nahradit UseMvc nebo UseSignalR za UseEndpoints.

• Pokud aplikace používá scénáře CORS , například [EnableCors], umístěte volání před UseCors jakýkoli jiný middleware, který používá CORS (například místo UseCors před UseAuthentication, UseAuthorizationa UseEndpoints).

• IWebHostEnvironment Nahraďte IHostingEnvironment a přidejte using příkaz pro Microsoft.AspNetCore.Hosting obor názvů.

• Nahradit IApplicationLifetime ( IHostApplicationLifetimeMicrosoft.Extensions.Hosting obor názvů).

• Nahradit EnvironmentName ( EnvironmentsMicrosoft.Extensions.Hosting obor názvů).

Následující kód je příkladem Startup.Configure typické aplikace ASP.NET Core 2.2:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseStaticFiles();

    app.UseAuthentication();

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

    app.UseMvc(routes =>
    {
        routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
    });
}

Po aktualizaci předchozího Startup.Configure kódu:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseStaticFiles();

    app.UseRouting();

    app.UseCors();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>("/chat");
        endpoints.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
    });
}

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 tématu Kontroly stavu v ASP.NET Core.

Pokyny k middlewaru zabezpečení

Podpora autorizace a CORS je sjednocená s přístupem middlewaru. To umožňuje použití stejného middlewaru a funkcí v těchto scénářích. V této verzi je k dispozici aktualizovaný middleware autorizace a middleware CORS je vylepšený tak, aby porozuměl atributům používaným kontrolery MVC.

CORS

Dříve mohlo být obtížné nakonfigurovat CORS. Middleware byl k dispozici pro použití v některých případech, ale filtry MVC byly určeny k použití bez middlewaru v jiných případech použití. S ASP.NET Core 3.0 doporučujeme, aby všechny aplikace, které vyžadují CORS, používaly middleware CORS společně se směrováním koncových bodů. UseCors lze zadat s výchozí zásadou a [EnableCors] [DisableCors] atributy lze použít k přepsání výchozí zásady tam, kde je to potřeba.

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

• CORS je povolená pro všechny koncové body s pojmenovanou zásadou default .
• Třída MyController zakáže CORS s atributem [DisableCors] .

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseCors("default");

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

[DisableCors]
public class MyController : ControllerBase
{
    ...
}

Autorizace

V dřívějších verzích ASP.NET Core byla prostřednictvím atributu [Authorize] poskytována podpora autorizace. Middleware pro autorizaci nebyl k dispozici. V ASP.NET Core 3.0 se vyžaduje middleware autorizace. Doporučujeme umístit middleware ASP.NET Core Authorization (UseAuthorization) ihned po UseAuthentication. Middleware pro autorizaci je také možné nakonfigurovat s výchozí zásadou, kterou je možné přepsat.

V ASP.NET Core 3.0 nebo novější se UseAuthorization volá Startup.Configurea následující HomeController vyžaduje přihlášeného uživatele:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

public class HomeController : Controller
{
    [Authorize]
    public IActionResult BuyWidgets()
    {
        ...
    }
}

Při použití směrování koncového bodu doporučujeme konfiguraci AuthorizeFilter a místo toho se spoléhat na middleware autorizace. Pokud aplikace používá AuthorizeFilter jako globální filtr v MVC, doporučujeme refaktoring kódu poskytnout zásadu AddAuthorizationvolání .

Na DefaultPolicy začátku je nakonfigurovaná tak, aby vyžadovala ověřování, takže není nutná žádná další konfigurace. V následujícím příkladu jsou koncové body MVC označené jako RequireAuthorization tak, aby všechny požadavky měly být autorizované na DefaultPolicyzákladě . Přístup HomeController však umožňuje bez přihlášení uživatele k aplikaci z důvodu [AllowAnonymous]:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute().RequireAuthorization();
    });
}

[AllowAnonymous]
public class HomeController : Controller
{
    ...
}

Autorizace pro konkrétní koncové body

Autorizaci je také možné nakonfigurovat pro konkrétní třídy koncových bodů. Následující kód je příkladem převodu aplikace MVC, která nakonfigurovala globální AuthorizeFilter aplikaci na aplikaci s konkrétní zásadou vyžadující autorizaci:

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    static readonly string _RequireAuthenticatedUserPolicy = 
                            "RequireAuthenticatedUserPolicy";
    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(
                Configuration.GetConnectionString("DefaultConnection")));
        services.AddDefaultIdentity<IdentityUser>(
                 options => options.SignIn.RequireConfirmedAccount = true)
            .AddEntityFrameworkStores<ApplicationDbContext>();

        // Pre 3.0:
        // services.AddMvc(options => options.Filters.Add(new AuthorizeFilter(...));

        services.AddControllersWithViews();
        services.AddRazorPages();
        services.AddAuthorization(o => o.AddPolicy(_RequireAuthenticatedUserPolicy,
                        builder => builder.RequireAuthenticatedUser()));

    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseDatabaseErrorPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
            app.UseHsts();
        }
        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

        app.UseAuthentication();
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapDefaultControllerRoute()
                .RequireAuthorization(_RequireAuthenticatedUserPolicy);
            endpoints.MapRazorPages();
        });
    }
}

Zásady je také možné přizpůsobit. Je DefaultPolicy nakonfigurovaná tak, aby vyžadovala ověřování:

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(
                Configuration.GetConnectionString("DefaultConnection")));
        services.AddDefaultIdentity<IdentityUser>(
                 options => options.SignIn.RequireConfirmedAccount = true)
            .AddEntityFrameworkStores<ApplicationDbContext>();

        services.AddControllersWithViews();
        services.AddRazorPages();
        services.AddAuthorization(options =>
        {
            options.DefaultPolicy = new AuthorizationPolicyBuilder()
              .RequireAuthenticatedUser()
              .Build();
        });

    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseDatabaseErrorPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
            app.UseHsts();
        }
        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

        app.UseAuthentication();
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapDefaultControllerRoute().RequireAuthorization();
            endpoints.MapRazorPages();
        });
    }
}

[AllowAnonymous]
public class HomeController : Controller
{

Alternativně je možné nakonfigurovat všechny koncové body tak, aby vyžadovaly autorizaci bez [Authorize] konfigurace nebo RequireAuthorization konfigurace FallbackPolicy. Liší FallbackPolicy se od DefaultPolicy. Aktivuje se DefaultPolicy [Authorize] nebo RequireAuthorization, zatímco FallbackPolicy se aktivuje, když není nastavena žádná jiná zásada. FallbackPolicy je původně nakonfigurovaný tak, aby povoloval požadavky bez autorizace.

Následující příklad je stejný jako předchozí DefaultPolicy příklad, ale používá FallbackPolicy k tomu, aby vždy vyžadoval ověřování ve všech koncových bodech, s výjimkou případů, kdy [AllowAnonymous] je zadán:

public void ConfigureServices(IServiceCollection services)
{
    ...

    services.AddAuthorization(options =>
    {
        options.FallbackPolicy = new AuthorizationPolicyBuilder()
          .RequireAuthenticatedUser()
          .Build();
    });
}

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

[AllowAnonymous]
public class HomeController : Controller
{
    ...
}

Autorizace pomocí middlewaru funguje bez architektury, která má konkrétní znalosti autorizace. Například kontroly stavu nemají žádné konkrétní znalosti o autorizaci, ale kontroly stavu můžou mít konfigurovatelné zásady autorizace použité middlewarem.

Každý koncový bod navíc může přizpůsobit své požadavky na autorizaci. V následujícím příkladu UseAuthorization zpracovává autorizaci pomocí koncového DefaultPolicybodu kontroly stavu, ale /healthz koncový bod kontroly stavu vyžaduje admin uživatele:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints
            .MapHealthChecks("/healthz")
            .RequireAuthorization(new AuthorizeAttribute(){ Roles = "admin", });
    });
}

Ochrana se implementuje v některých scénářích. Middleware koncových bodů vyvolá výjimku, pokud se kvůli chybějícímu middlewaru přeskočí zásady autorizace nebo CORS. Podpora analyzátoru, která poskytuje další zpětnou vazbu o chybné konfiguraci, probíhá.

Vlastní obslužné rutiny autorizace

Pokud aplikace používá vlastní autorizační obslužné rutiny, směrování koncového bodu předá obslužným rutinám jiný typ prostředku než MVC. Obslužné rutiny, které očekávají, že kontextový prostředek obslužné rutiny autorizace bude typu AuthorizationFilterContext (typ prostředku poskytovaný filtry MVC), bude potřeba aktualizovat tak, aby zpracovávaly prostředky typu RouteEndpoint (typ prostředku udělený obslužným rutinám autorizace směrováním koncového bodu).

MVC stále používá AuthorizationFilterContext prostředky, takže pokud aplikace používá autorizační filtry MVC spolu s autorizací směrování koncových bodů, může být nutné zpracovat oba typy prostředků.

SignalR

SignalR Mapování rozbočovačů teď probíhá uvnitř UseEndpoints.

Namapujte každé centrum pomocí MapHub. Stejně jako v předchozích verzích je každé centrum explicitně uvedené.

V následujícím příkladu ChatHubSignalR se přidá podpora centra:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>();
    });
}

Existuje nová možnost pro řízení limitů velikosti zpráv od klientů. Například v Startup.ConfigureServices:

services.AddSignalR(hubOptions =>
{
    hubOptions.MaximumReceiveMessageSize = 32768;
});

V ASP.NET Core 2.2 můžete nastavit TransportMaxBufferSize velikost zprávy, která by efektivně kontrolovala maximální velikost zprávy. V ASP.NET Core 3.0 teď tato možnost řídí maximální velikost pouze před pozorováním backpressure.

SignalR sestavení ve sdíleném rozhraní

ASP.NET sestavení na straně serveru se SignalR teď instalují se sadou .NET Core SDK. Další informace naleznete v tématu Odebrání zastaralých odkazů na balíčky v tomto dokumentu.

Kontrolery MVC

Mapování kontrolerů probíhá uvnitř UseEndpoints.

Přidejte MapControllers , pokud aplikace používá směrování atributů. Vzhledem k tomu, že směrování zahrnuje podporu pro mnoho architektur v ASP.NET Core 3.0 nebo novější, přidání kontrolerů směrovaných atributů je výslovný souhlas.

Nahraďte následující položky:

• MapRoute s MapControllerRoute
• MapAreaRoute s MapAreaControllerRoute

Vzhledem k tomu, že směrování teď zahrnuje podporu více než jen MVC, terminologie se změnila, aby tyto metody jasně uvedly, co dělají. Běžné trasy, jako MapControllerRoute//MapAreaControllerRouteMapDefaultControllerRoute jsou použité v pořadí, v jakém jsou přidány. Nejprve umístěte konkrétnější trasy (například trasy pro oblast).

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

• MapControllers přidává podporu pro kontrolery směrované atributy.
• MapAreaControllerRoute přidá konvenční trasu pro kontrolery v oblasti.
• MapControllerRoute přidá konvenční trasu pro kontrolery.

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
        endpoints.MapAreaControllerRoute(
            "admin",
            "admin",
            "Admin/{controller=Home}/{action=Index}/{id?}");
        endpoints.MapControllerRoute(
            "default", "{controller=Home}/{action=Index}/{id?}");
    });
}

Odebrání asynchronní přípony z názvů akcí kontroleru

V ASP.NET Core 3.0 ASP.NET Core MVC odebere příponu Async z názvů akcí kontroleru. Toto nové výchozí nastavení má vliv na generování směrování i propojení. Příklad:

public class ProductsController : Controller
{
    public async Task<IActionResult> ListAsync()
    {
        var model = await _dbContext.Products.ToListAsync();
        return View(model);
    }
}

Před ASP.NET Core 3.0:

• Předchozí akci je možné získat přístup na trase Products/ListAsync .

• Generování propojení vyžaduje zadání přípony Async . Příklad:

  <a asp-controller="Products" asp-action="ListAsync">List</a>
  

V ASP.NET Core 3.0:

• Předchozí akci je možné získat přístup na trase Products/List .

• Generování propojení nevyžaduje zadání přípony Async . Příklad:

  <a asp-controller="Products" asp-action="List">List</a>
  

Tato změna nemá vliv na názvy zadané pomocí atributu [ActionName] . Výchozí chování může být zakázáno s následujícím kódem v Startup.ConfigureServices:

services.AddMvc(options =>
    options.SuppressAsyncSuffixInActionNames = false);

Změny generování propojení

V generování propojení (například pomocí Url.Link a podobných rozhraní API) existují určité rozdíly. Tady jsou některé z nich:

• Při použití směrování koncového bodu se při použití směrování koncového bodu nemusí zachovat velikost velikostí parametrů trasy ve vygenerovaných identifikátorech URI. Toto chování lze ovládat pomocí IOutboundParameterTransformer rozhraní.
• Generování identifikátoru URI pro neplatnou trasu (kontroler/akci nebo stránku, která neexistuje), vytvoří prázdný řetězec pod směrováním koncového bodu místo vytvoření neplatného identifikátoru URI.
• Okolní hodnoty (parametry trasy z aktuálního kontextu) se při generování propojení se směrováním koncového bodu nepoužívají automaticky. Dříve se při generování odkazu na jinou akci (nebo stránku) odvozovaly nezadané hodnoty trasy z aktuálních tras okolních hodnot. Při použití směrování koncového bodu musí být během generování propojení explicitně zadány všechny parametry trasy.

Razor Pages

Mapovací Razor stránky se nyní provádí uvnitř UseEndpoints.

Přidejte MapRazorPages , pokud aplikace používá Razor stránky. Vzhledem k tomu, že směrování koncových bodů zahrnuje podporu pro mnoho architektur, přidávání Razor stránek je teď výslovné.

V následující Startup.Configure metodě MapRazorPages přidá podporu pro Razor Pages:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

Použití MVC bez směrování koncového bodu

Použití MVC prostřednictvím UseMvc nebo UseMvcWithDefaultRoute v ASP.NET Core 3.0 vyžaduje explicitní souhlas uvnitř Startup.ConfigureServices. To je povinné, protože MVC musí vědět, jestli se může během inicializace spoléhat na autorizaci a middleware CORS. K dispozici je analyzátor, který varuje, pokud se aplikace pokusí použít nepodporovanou konfiguraci.

Pokud aplikace vyžaduje starší IRouter verzi podpory, zakažte EnableEndpointRouting použití některého z následujících přístupů v Startup.ConfigureServices:

services.AddMvc(options => options.EnableEndpointRouting = false);

services.AddControllers(options => options.EnableEndpointRouting = false);

services.AddControllersWithViews(options => options.EnableEndpointRouting = false);

services.AddRazorPages().AddMvcOptions(options => options.EnableEndpointRouting = false);

Kontroly stavu

Kontroly stavu se dají použít jako router-ware se směrováním koncových bodů.

Přidejte MapHealthChecks k používání kontrol stavu se směrováním koncových bodů. Metoda MapHealthChecks přijímá argumenty podobné UseHealthChecks. Výhodou použití MapHealthChecks UseHealthChecks oproti tomu je možnost použít autorizaci a mít větší podrobnou kontrolu nad odpovídajícími zásadami.

V následujícím příkladu MapHealthChecks se volá koncový bod kontroly stavu na /healthzadrese:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHealthChecks("/healthz", new HealthCheckOptions() { });
    });
}

HostBuilder nahrazuje WebHostBuilder.

Šablony ASP.NET Core 3.0 používají obecného hostitele. Předchozí verze používaly webového hostitele. Následující kód ukazuje vygenerovanou Program třídu šablony ASP.NET Core 3.0:

// requires using Microsoft.AspNetCore.Hosting;
// requires using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

Následující kód ukazuje třídu vygenerovanou Program šablonou ASP.NET Core 2.2:

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();
}

IWebHostBuilder zůstává ve verzi 3.0 a je typem webBuilder předchozího vzorku kódu. WebHostBuilderbude vyřazena v budoucí verzi a nahrazena .HostBuilder

Nejvýznamnější změna od WebHostBuilder injektáže HostBuilder závislostí (DI) Při použití HostBuildermůžete do Startupkonstruktoru 's vložit pouze následující:

• IConfiguration
• IHostEnvironment
• IWebHostEnvironment

Omezení HostBuilder DI:

• Povolte sestavení kontejneru DI pouze jednou.
• Vyhne se problémům s životností výsledného objektu, jako je řešení více instancí singletonů.

Další informace najdete v tématu Zabránění injektáži služby po spuštění v ASP.NET Core 3.

PřidáníAuthorizace přesunutá do jiného sestavení

Metody ASP.NET Core 2.2 a nižší AddAuthorization v Microsoft.AspNetCore.Authorization.dll:

• Byly přejmenovány AddAuthorizationCore.
• Byly přesunuty do Microsoft.AspNetCore.Authorization.Policy.dll.

Aplikace, které používají Microsoft.AspNetCore.Authorization.dll i Microsoft.AspNetCore.Authorization.Policy.dll , nemají vliv.

Aplikace, které nepoužívají Microsoft.AspNetCore.Authorization.Policy.dll by měly provádět jednu z následujících věcí:

• Přidejte odkaz na Microsoft.AspNetCore.Authorization.Policy.dll. Tento přístup funguje pro většinu aplikací a je to vše, co je potřeba.
• Přepnutí na používání AddAuthorizationCore

Další informace naleznete v tématu Zásadní změna v AddAuthorization(o =>) přetížení žije v jiném sestavení č. 386.

Identity UI

Identity Aktualizace uživatelského rozhraní pro ASP.NET Core 3.0:

• Přidejte odkaz na balíček Microsoft.AspNetCore .Identity. Uživatelské rozhraní.
• Aplikace, které nepoužívají Razor stránky, musí volat MapRazorPages. Viz Razor Stránky v tomto dokumentu.
• Bootstrap 4 je výchozí architektura uživatelského rozhraní. IdentityUIFrameworkVersion Nastavte vlastnost projektu tak, aby se výchozí nastavení změnilo. Další informace najdete v tomto oznámení GitHubu.

SignalR

Klient JavaScriptu SignalR se změnil z @aspnet/signalr na @microsoft/signalr. Pokud chcete na tuto změnu reagovat, změňte odkazy v package.json souborech, require příkazech a příkazech ECMAScript import .

System.Text.Json je výchozí protokol.

System.Text.Json je teď výchozí protokol centra používaný klientem i serverem.

AddJsonProtocol Volání Startup.ConfigureServicespro nastavení možností serializátoru.

Server:

services.AddSignalR(...)
        .AddJsonProtocol(options =>
        {
            options.PayloadSerializerOptions.WriteIndented = false;
        })

Klient:

new HubConnectionBuilder()
    .WithUrl("/chathub")
    .AddJsonProtocol(options =>
    {
        options.PayloadSerializerOptions.WriteIndented = false;
    })
    .Build();

Přepnutí na Newtonsoft.Json

Pokud používáte funkce Newtonsoft.Json, které nejsou v souboru System.Text.Json podporované, můžete přepnout zpět na Newtonsoft.Json. Viz Použití Newtonsoft.Json v projektu ASP.NET Core 3.0 SignalR výše v tomto článku.

Distribuované mezipaměti Redis

Balíček Microsoft.Extensions.Caching.Redis není k dispozici pro aplikace ASP.NET Core 3.0 nebo novější. Nahraďte odkaz na balíček microsoft.Extensions.Caching.StackExchangeRedis. Další informace naleznete v tématu Distribuované ukládání do mezipaměti v ASP.NET Core.

Přihlášení k kompilaci modulu runtime

Před ASP.NET Core 3.0 byla implicitní funkcí architektury kompilace zobrazení za běhu. Kompilace modulu runtime doplňuje kompilaci zobrazení v čase sestavení. Umožňuje rozhraní kompilovat Razor zobrazení a stránky (.cshtml soubory) při úpravě souborů, aniž by bylo nutné znovu sestavit celou aplikaci. Tato funkce podporuje scénář rychlé úpravy v integrovaném vývojovém prostředí (IDE) a aktualizaci prohlížeče pro zobrazení změn.

V ASP.NET Core 3.0 je kompilace modulu runtime scénářem výslovného souhlasu. Kompilace v době sestavení je jediným mechanismem pro zobrazení kompilace, která je ve výchozím nastavení povolená. Modul runtime spoléhá na Visual Studio nebo dotnet-watch v editoru Visual Studio Code k opětovnému sestavení projektu při zjišťování změn souborů .cshtml . V sadě Visual Studio se změny , .cshtml.csnebo .razor soubory v projektu spouští (Ctrl+F5), ale ne laděné (F5), aktivují rekompilace projektu.

Povolení kompilace modulu runtime v projektu ASP.NET Core 3.0:

1. Nainstalujte Microsoft.AspNetCore.Mvc.Razor. Balíček NuGet runtimeCompilation

2. Aktualizovat Startup.ConfigureServices na volání AddRazorRuntimeCompilation:

   Pro ASP.NET Core MVC použijte následující kód:

   services.AddControllersWithViews()
       .AddRazorRuntimeCompilation(...);
   

   Pro ASP.NET základní Razor stránky použijte následující kód:

   services.AddRazorPages()
       .AddRazorRuntimeCompilation(...);
   

Ukázka na obrázku https://github.com/aspnet/samples/tree/main/samples/aspnetcore/mvc/runtimecompilation ukazuje příklad podmíněného povolení kompilace modulu runtime ve vývojových prostředích.

Další informace o Razor kompilaci souborů naleznete Razor v souboru kompilace v ASP.NET Core.

Migrace knihoven prostřednictvím cílení na více verzí

Knihovny často potřebují podporovat více verzí ASP.NET Core. Většina knihoven zkompilovaných oproti předchozím verzím ASP.NET Core by měla bez problémů pokračovat v práci. Následující podmínky vyžadují, aby byla aplikace křížově zkompilována:

• Knihovna spoléhá na funkci, která má binární zásadní změnu.
• Knihovna chce využívat nové funkce v ASP.NET Core 3.0.

Příklad:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netcoreapp3.0;netstandard2.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.0'">
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
    <PackageReference Include="Microsoft.AspNetCore" Version="2.1.0" />
  </ItemGroup>
</Project>

Slouží #ifdefs k povolení rozhraní API specifických pro ASP.NET Core 3.0:

var webRootFileProvider =
#if NETCOREAPP3_0
    GetRequiredService<IWebHostEnvironment>().WebRootFileProvider;
#elif NETSTANDARD2_0
    GetRequiredService<IHostingEnvironment>().WebRootFileProvider;
#else
#error unknown target framework
#endif

Další informace o používání rozhraní ASP.NET Core API v knihovně tříd najdete v tématu Použití rozhraní API ASP.NET Core v knihovně tříd.

Různé změny

Ověřovací systém v .NET Core 3.0 a novější považuje parametry bez hodnoty null nebo vázané vlastnosti, jako by měly [Required] atribut. Další informace naleznete v tématu [Povinný] atribut.

Publikovat

Odstraňte složky bin a obj v adresáři projektu.

TestServer

Pro aplikace, které používají TestServer přímo s obecným hostitelem, vytvořte na TestServer kartě IWebHostBuilder ConfigureWebHost:

[Fact]
public async Task GenericCreateAndStartHost_GetTestServer()
{
    using var host = await new HostBuilder()
        .ConfigureWebHost(webBuilder =>
        {
            webBuilder
                .UseTestServer()
                .Configure(app => { });
        })
    .StartAsync();

    var response = await host.GetTestServer().CreateClient().GetAsync("/");

    Assert.Equal(HttpStatusCode.NotFound, response.StatusCode);
}

Zásadní změny rozhraní API

Kontrola zásadních změn:

• Úplný seznam zásadních změn ve verzi ASP.NET Core 3.0
• Rozbíjející změny rozhraní API v antiforgery, CORS, diagnostice, MVC a směrování Tento seznam obsahuje zásadní změny pro přepínače kompatibility.
• Souhrn zásadních změn 2.2-to-3.0 napříč .NET Core, ASP.NET Core a Entity Framework Core najdete v tématu Zásadní změny migrace z verze 2.2 na verzi 3.0.

Směrování koncového bodu s parametrem catch-all

public static void Main(string[] args)
{
   AppContext.SetSwitch("Microsoft.AspNetCore.Routing.UseCorrectCatchAllBehavior", 
                         true);
   CreateHostBuilder(args).Build().Run();
}
// Remaining code removed for brevity.

.NET Core 3.0 ve službě Aplikace Azure

Zavedení rozhraní .NET Core do služby Aplikace Azure je dokončené. .NET Core 3.0 je k dispozici ve všech datacentrech Aplikace Azure Service.

modul ASP.NET Core (ANCM)

Pokud ASP.NET Core Module (ANCM) nebyla vybraná komponenta při instalaci sady Visual Studio nebo pokud byla v systému nainstalována předchozí verze ANCM, stáhněte si nejnovější instalační program balíčku hostingu .NET Core (přímý stažení) a spusťte instalační program. Další informace naleznete v tématu Hosting Bundle.