migrace z ASP.NET Core 2,2 na 3,0

Scottem 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 příslušné změny do projektu ASP.NET Core 3,0.

Požadavky

Aktualizace verze .NET Core SDK v global.js

Pokud vaše řešení spoléhá na global.js souboru, aby cílí na konkrétní .NET Core SDKou verzi, aktualizujte jeho version vlastnost na verzi 3,0 nainstalovanou na vašem počítači:

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

Aktualizovat soubor projektu

Aktualizace cílového rozhraní .NET Framework

ASP.NET Core 3,0 a novější se spouští pouze v .net Core. Nastavte moniker cílového rozhraní .NET Framework (TFM) na netcoreapp3.0 :

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

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

</Project>

Odebrat zastaralé odkazy na balíčky

pro ASP.NET Core 3,0 se nevyprodukuje velký počet balíčků NuGet. Tyto odkazy na balíčky by měly být odebrány ze souboru projektu. vezměte v úvahu 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áno. Další informace najdete v tématu Reference k rozhraní v tomto dokumentu.
  • Microsoft.AspNetCore.Razor.Design odebrána a v následujícím seznamu balíčků již nejsou vytvářeny.

Úplný seznam balíčků, které už nejsou vytvořené, zobrazíte tak, že vyberete následující seznam rozbalit:

Kontrola změn s rozbíjením

Kontrola změn s rozbíjením

Referenční informace k rozhraní

Funkce ASP.NET Core, které byly dostupné prostřednictvím jednoho z výše uvedených balíčků, jsou k dispozici jako součást Microsoft.AspNetCore.App sdílené architektury. Sdílená rozhraní je sada sestavení (.dll souborů), které jsou nainstalovány v počítači a obsahují komponentu modulu runtime a cílovou sadu. Další informace najdete v tématu Sdílená rozhraní.

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

  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é Microsoft.NET.Sdk cílí Microsoft.NET.Sdk.Razor na nebo sadu SDK, by měly explicitně přidat FrameworkReference do 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í s využitím Dockeru

Sestavení konzolových aplikací závislých na rozhraní, která používají balíček, který závisí na ASP.NET Core rozhraní může způsobit následující chybu modulu runtime:

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.Appje sdílená rozhraní obsahující ASP.NET Core runtime a nachází se pouze v ibitové kopii Dockeru dotnet/core/aspnet. Sada SDK verze 3.0 zmenšuje velikost sestavení závislých na rozhraní pomocí ASP.NET Core tím, že nezadá duplicitní kopie knihoven, které jsou k dispozici ve sdíleném rozhraní. To může ušetřit až 18 MB, ale vyžaduje, aby ASP.NET Core byl k dispozici nebo nainstalován modul runtime pro spuštění aplikace.

Pokud chcete zjistit, jestli má aplikace závislost (buď přímo, nebo nepřímo) na sdílené ASP.NET Core, prozkoumejte souborruntimeconfig.js vygenerovaný během sestavení nebo publikování vaší aplikace. Následující soubor JSON ukazuje závislost na sdílené ASP.NET Core architektury:

{
  "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íček pro odebraná sestavení

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

Pokud chcete dál používat funkce poskytované odebranými sestaveními, odkašlte na verze 3.0 odpovídajících balíčků:

• Šablona vygenerovaná webová aplikace 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 specifický pro poskytovatele databáze najdete v tématu Poskytovatelé databáze.

• Identity UI

  Podporu Identity uživatelského rozhraní je možné 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 NuGet balíčky:

  • Facebook OAuth (Microsoft.AspNetCore.Authentication.Facebook)
  • Google OAuth (Microsoft.AspNetCore.Authentication.Google)
  • Ověřování účtu Microsoft (Microsoft.AspNetCore.Authentication.MicrosoftAccount)
  • OpenID Připojení ověřování (Microsoft.AspNetCore.Authentication.OpenIdConnect)
  • OpenID Připojení bearer token (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 System.Net.HttpClient Microsoft.AspNet.WebApi.Client NuGet poskytuje užitečnou rozšiřitelnost rozhraní API, jako jsou a System.Net.HttpClient ReadAsAsync PostJsonAsync .

• Razor kompilace modulu runtime: Podpora běhové kompilace zobrazení a stránek je teď Razor součástí Microsoft.AspNetCore.Mvc. Razor . RuntimeCompilation:

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

Změny po 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 nezískající kód možností, který byl cookie 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 zobrazí zeleně. Informace o následujících změnách:

• services.AddMvc na services.AddRazorPages , viz registrace služby MVC v tomto dokumentu.
• CompatibilityVersionnajdete v tématu Verze kompatibility pro ASP.NET Core MVC .
• IHostingEnvironmentna IWebHostEnvironment , viz toto GitHub oznámení.
• app.UseAuthorization byl přidán do šablon, aby bylo možné zobrazit, že je nutné přidat autorizační middleware pořadí. Pokud aplikace autorizaci nepou3/4í, můžete volání bezpečně app.UseAuthorization odebrat.
• app.UseEndpointsnajdete v Razor části Stránky nebo Startup.Configv tomto dokumentu.

Podpora analyzátoru

Projekty, které Microsoft.NET.Sdk.Web cílí na implicitně odkazované 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á analyzátory rozhraní API dříve dodávané pomocí balíčku Microsoft.AspNetCore.Mvc.Api.Analyzers, upravte soubor projektu tak, aby odkazovat na analyzátory dodávané jako součást sady .NET Core Web SDK:

<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í AddRazorSupportForMvc nastavit vlastnost v souboru projektu:

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

Model hostování v procesu

Projekty ve výchozím nastavení hostování v procesu v ASP.NET Core 3.0 nebo novější. Volitelně můžete odebrat vlastnost <AspNetCoreHostingModel> v souboru projektu, pokud má hodnotu InProcess .

Kestrel

Konfigurace

Migrace Kestrel konfigurace do tvůrce webového hostitele poskytovaného ConfigureWebHostDefaults službou (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 vytvoří hostitele ručně pomocí místo ConfigureWebHost ConfigureWebHostDefaults , zavolejte u tvůrce UseKestrel webového hostitele:

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 pro připojení nahrazuje adaptéry připojení

Z se Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter odebraly adaptéry připojení ( Kestrel ). Nahraďte Adaptéry připojení middlewarem připojení. Middleware pro připojení se podobá middlewaru HTTP v kanálu ASP.NET Core, ale pro připojení nižší úrovně. HTTPS a protokolování připojení:

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

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

Přenosové abstrakce se přesunuly a byly veřejné

Přenosová Kestrel vrstva byla zveřejně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 se přesunul z ListenOptions na možnosti přenosu.
• Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.Internal.SchedulingMode byl odebrán z KestrelServerOptions .

Další informace najdete v následujících zdrojích GitHub prostředků:

• Abstrakce sítě mezi klientem a serverem (dotnet/AspNetCore #10308)
• Implementace nové abstrakce naslouchacího procesu a opětovného nastavení Kestrel (dotnet/AspNetCore #10321)

Kestrel Hlavičky request trailer

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

• Kestrel přidá do kolekce hlaviček požadavků hlavičky HTTP/1.1 s hlavičkami v bloku.
• Po přečtení textu požadavku na konec jsou k dispozici koncovky.

To způsobuje určité obavy ohledně nejednoznačnosti mezi hlavičkami a upoutávky, takže se upísněné části přesunuly do nové kolekce ( ) ve RequestTrailerExtensions 3.0.

Požadavky HTTP/2:

• Není k dispozici ve ASP.NET Core 2.2.
• K dispozici ve 3.0 jako RequestTrailerExtensions .

Pro přístup k těmto upoutávkům jsou k dispozici nové metody rozšíření žádostí. Stejně jako u HTTP/1.1 jsou po přečtení textu požadavku na konec k dispozici koncovky.

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

• GetDeclaredTrailers: Získá hlavičku Trailer požadavku, která uvádí, které upoutávky se mají očekávat po těle.
• SupportsTrailers: Určuje, zda požadavek podporuje příjem hlaviček přípojných vozidel.
• CheckTrailersAvailable: Kontroluje, zda požadavek podporuje Přípojná místa, a pokud jsou k dispozici pro čtení. Tato kontrolu nepředpokládá, že existuje přívěsy ke čtení. Není možné, aby bylo možné číst bez přípojných míst, i když true je tato metoda vrácena.
• GetTrailer: Načte požadované koncové záhlaví z odpovědi. SupportsTrailersPřed voláním GetTrailer nebo se NotSupportedException může vyskytnout, pokud požadavek nepodporuje koncové hlavičky.

Další informace najdete v tématu o umístění přípojných vozidel v samostatné kolekci (dotnet/AspNetCore #10410).

AllowSynchronousIO zakázané

AllowSynchronousIO povoluje nebo zakazuje synchronní vstupně-výstupní rozhraní API, například, HttpRequest.Body.Read HttpResponse.Body.Write a Stream.Flush . Tato rozhraní API jsou zdrojem vyčerpání vláken, který vede k selhání aplikace. V 3,0 AllowSynchronousIO je ve výchozím nastavení zakázáno. Další informace najdete v části synchronní v/v Kestrel článku.

Pokud je potřeba synchronní vstupně-výstupní operace, můžete ji povolit nakonfigurováním AllowSynchronousIO Možnosti na používaném serveru (například při volání ConfigureKestrel Kestrel ). Upozorňujeme, že servery ( Kestrel , HttpSys, TestServer atd.) mají svou vlastní AllowSynchronousIO možnost, která nebude mít vliv na ostatní servery. Synchronní vstupně-výstupní operace lze povolit pro všechny servery na základě jednotlivých požadavků pomocí IHttpBodyControlFeature.AllowSynchronousIO Možnosti:

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

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

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

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

Výstupní vyrovnávací paměť formátovacího modulu

Výstupní formátovací moduly založené na,Newtonsoft.Js, XmlSerializer a DataContractSerializer podporují pouze synchronní serializaci. Aby mohly tyto formátovací moduly fungovat s AllowSynchronousIOmi omezeními serveru, MVC před zápisem na disk uloží výstup těchto formátovacích modulů do vyrovnávací paměti. V důsledku ukládání do vyrovnávací paměti MVC zahrne záhlaví Content-Length při reagování na použití těchto formátovacích modulů.

System.Text.Json podporuje asynchronní serializaci a v důsledku toho System.Text.Json formátování na bázi neukládá do vyrovnávací paměti. Zvažte použití tohoto formátovacího modulu pro zlepšení výkonu.

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

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

Všimněte si, že to může způsobit, že aplikace vyvolává výjimku za běhu, pokud AllowSynchronousIO není nakonfigurována také.

Microsoft. AspNetCore. Server. Kestrel .. Bylo odebráno sestavení https.

v ASP.NET Core 2,1 se obsah microsoft. AspNetCore. server. Kestrel.Https.dll přesunul do microsoft. AspNetCore. server. Kestrel.Core.dll. Toto byla neprůlomová aktualizace pomocí TypeForwardedTo atributů. pro 3,0 byla odebrána prázdná sestavení Microsoft. AspNetCore. Server. Kestrel.Https.dll a balíček NuGet.

Knihovny odkazující na Microsoft. AspNetCore. Server. Kestrel . protokol Https by měl aktualizovat ASP.NET Core závislosti na 2,1 nebo novější.

aplikace a knihovny cílené na ASP.NET Core 2,1 nebo novější by měly odebrat jakékoli přímé odkazy na Microsoft. AspNetCore. Server. Kestrel Balíček https .

Podpora Newtonsoft.Json (Json.NET)

jako součást práce pro zlepšení ASP.NET Core sdíleného rozhraníse Newtonsoft.Jsna (Json.NET) odebrala ze ASP.NET Core sdílené architektury.

výchozí serializátor JSON pro ASP.NET Core je teď System.Text.Json , což je v .net Core 3,0 nové. Zvažte použití System.Text.Json , pokud je to možné. Je to vysoký výkon a nevyžaduje další závislost knihovny. Jelikož je však System.Text.Json novinkou, může v současnosti chybět funkce, které vaše aplikace potřebuje. Další informace najdete v tématu Postup migrace z Newtonsoft.Jsna do System.Text.Jsna.

použití Newtonsoft.Jsv projektu ASP.NET Core 3,0 SignalR

• Nainstalujte Microsoft. AspNetCore. SignalR . NewtonsoftJson balíček protocols. reNuGet.

• Na straně klienta řetězit AddNewtonsoftJsonProtocol volání metody do HubConnectionBuilder instance:

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

• Na serveru řetězit AddNewtonsoftJsonProtocol volání AddSignalR metody volání metody Startup.ConfigureServices :

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

použití Newtonsoft.Jsv projektu ASP.NET Core 3,0 MVC

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

• Aktualizujte Startup.ConfigureServices volání 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 v volání AddNewtonsoftJson :

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

  Poznámka: Pokud tato AddNewtonsoftJson metoda není k dispozici, ujistěte se, že jste Microsoft.AspNetCore.Mvc.NewtonsoftJson balíček nainstalovali. Běžnou chybou je instalace Newtonsoft.Jsdo balíčku namí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.Js.

Registrace služby MVC

ASP.NET Core 3,0 přidává nové možnosti pro registraci scénářů MVC v rámci Startup.ConfigureServices .

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

Následující příklad přidá podporu pro řadiče 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 řadiče, 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();
}

V následujícím příkladu je přidána podpora pro Razor stránky a minimální Podpora řadičů. Š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();
}

Spouštěcí kód směrování

Pokud je to aplikace UseMvc , nebo pokud je UseSignalR to možné, proveďte migraci aplikace do Směrování koncových bodů . pro zlepšení kompatibility směrování koncových bodů s předchozími verzemi MVC jsme vrátili některé změny v adrese URL představené v ASP.NET Core 2,2. pokud jste narazili na problémy s používáním směrování koncových bodů v 2,2, můžete očekávat vylepšení ASP.NET Core 3,0 s následujícími výjimkami:

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

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

Pro většinu aplikací vyžaduje pouze Startup změny.

Migrace Startup.Configurovat

Obecné pokyny:

• Přidat UseRouting .

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

• Pokud aplikace používá funkce ověřování/autorizace, jako je AuthorizePage nebo [Authorize] , umístěte volání do UseAuthentication a UseAuthorization : After 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();
    });
  

• Nahraďte UseMvc nebo UseSignalR s UseEndpoints .

• Pokud aplikace používá scénáře CORS , například [EnableCors] , umístěte volání do UseCors jakéhokoli jiného middlewaru, který používá CORS (například na místo UseCors před UseAuthentication , UseAuthorization a UseEndpoints ).

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

• Nahraďte IApplicationLifetime IHostApplicationLifetime ( Microsoft.Extensions.Hosting oborem názvů).

• Nahraďte EnvironmentName Environments ( Microsoft.Extensions.Hosting oborem 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ů u obecného hostitele. V Startup.Configure nástroji zavolejte MapHealthChecks na tvůrce koncového bodu s adresou URL koncového bodu nebo relativní cestou:

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

Koncové body kontrol stavu můžou:

• Zadejte minimálně jednoho povoleného hostitele nebo portů.
• Vyžadovat autorizaci.
• Vyžadovat CORS

Další informace naleznete v tématu Kontroly stavu v ASP.NET Core.

Doprovodné materiály k zabezpečení middlewaru

Podpora pro autorizaci a CORS je sjednocená v rámci přístupu middlewaru . To umožňuje používat stejný middlewar a funkčnost v těchto scénářích. V této verzi je k dispozici aktualizovaný middleware autorizace a middleware CORS je vylepšený, aby bylo možné pochopit atributy používané řadiči MVC.

CORS

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

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

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

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 podpora autorizace poskytována prostřednictvím [Authorize] atributu . Autorizační middleware nebyl k dispozici. Ve ASP.NET Core 3.0 se vyžaduje autorizační middleware. Doporučujeme umístit ASP.NET Core autorizační middleware ( UseAuthorization ) hned za UseAuthentication . Autorizační middleware je také možné nakonfigurovat s výchozí zásadou, kterou je možné přepsat.

V ASP.NET Core verze 3.0 nebo novější se volá v a následující příkaz vyžaduje UseAuthorization Startup.Configure HomeController přihlášené 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ých bodů doporučujeme, abyste se místo toho nespoléhají na AuthorizeFilter autorizační middleware. Pokud aplikace používá v MVC jako globální filtr, doporučujeme AuthorizeFilter kód refaktorovat a poskytnout tak zásadu ve volání AddAuthorization .

Vlastnost DefaultPolicy je zpočátku nakonfigurovaná tak, aby vyžadovala ověření, takže se nevyžaduje žádná další konfigurace. V následujícím příkladu jsou koncové body MVC označené jako , aby všechny požadavky musely RequireAuthorization být autorizovány na základě DefaultPolicy . Umožňuje ale přístup bez přihlášení uživatele HomeController k aplikaci z následujícího [AllowAnonymous] důvodu:

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á nakonfiguroval globální na aplikaci s konkrétní zásadou vyžadující AuthorizeFilter 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
{

Další možností je nakonfigurovat všechny koncové body tak, aby vyžadovaly autorizaci bez konfigurace [Authorize] RequireAuthorization nebo . FallbackPolicy se FallbackPolicy liší od DefaultPolicy . Aktivuje DefaultPolicy se pomocí nebo , když se [Authorize] RequireAuthorization FallbackPolicy aktivuje, když není nastavená žádná jiná zásada. FallbackPolicy je zpočátku nakonfigurovaný tak, aby povoloval požadavky bez autorizace.

Následující příklad je stejný jako v předchozím příkladu, ale pomocí metody vždy vyžaduje ověření na všech koncových bodech DefaultPolicy FallbackPolicy s výjimkou [AllowAnonymous] případů, kdy je zadaný parametr :

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 middlewarem funguje, aniž by rozhraní měla nějaké konkrétní znalosti o autorizaci. Například kontroly stavu nemají žádné konkrétní znalosti o autorizaci, ale kontroly stavu mohou mít konfigurovatelné zásady autorizace použité middlewarem.

Každý koncový bod může navíc přizpůsobit své požadavky na autorizaci. V následujícím příkladu zpracovává UseAuthorization autorizaci pomocí DefaultPolicy , ale koncový bod kontroly stavu vyžaduje /healthz 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", });
    });
}

Pro některé scénáře je implementovaná ochrana. Middleware koncového bodu vyvolá výjimku, pokud se kvůli chybějícímu middlewaru přeskočí autorizace nebo zásady CORS. Probíhá podpora analyzátoru, která poskytuje další zpětnou vazbu o chybné konfiguraci.

Vlastní obslužné rutiny autorizace

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

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

SignalR

Mapování SignalR center teď probíhá uvnitř UseEndpoints .

Namapovat každý rozbočovač na MapHub . Stejně jako v předchozích verzích je každé centrum explicitně uvedené.

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

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

K dispozici je nová možnost řízení omezení velikosti zpráv od klientů. Například v Startup.ConfigureServices souboru :

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

V ASP.NET Core 2.2 byste mohli nastavit a , které by efektivně TransportMaxBufferSize řídit maximální velikost zprávy. Ve ASP.NET Core 3.0 tato možnost řídí maximální velikost pouze před zpozorování backpressu.

Kontrolery MVC

Mapování kontrolerů teď 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 rozhraní v ASP.NET Core 3.0 nebo novější, přidání kontrolerů směrovaných na atributy je výslovný souhlas.

Nahraďte následující:

• MapRoute S MapControllerRoute
• MapAreaRoute S MapAreaControllerRoute

Vzhledem k tomu, že směrování teď zahrnuje podporu více než jenom MVC, terminologie se změnila, aby tyto metody jasně popisovat, co dělají. Konvenční trasy, jako jsou , se použijí v pořadí, MapControllerRoute / MapAreaControllerRoute / MapDefaultControllerRoute ve které se přidávají. 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 kontrolerů směrovaných na 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í ovlivňuje směrování i generování 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:

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

• Vyžaduje se generování propojení určující Async příponu. Příklad:

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

Ve ASP.NET Core 3.0:

• Předchozí akce je přístupná na trase Products/List.

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

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

Tato změna nemá vliv na názvy zadané pomocí [ActionName] atributu . Výchozí chování je možné zakázat pomocí následujícího kódu v Startup.ConfigureServices souboru :

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

Změny generování propojení

Jak je vysvětleno v dokumentaci k rozdílůmoproti dřívějším verzím směrování , existují určité rozdíly v generování propojení (například pomocí podobných Url.Link rozhraní API). Tady jsou některé z nich:

• Při použití směrování koncových bodů se ve výchozím nastavení velikostí kaskádových parametrů trasy ve vygenerované identifikátory URI nemusí nutně zachovat. Toto chování lze řídit pomocí IOutboundParameterTransformer rozhraní .
• Generování identifikátoru URI pro neplatnou trasu (kontroler/ akce nebo stránka, která neexistuje) vytvoří prázdný řetězec pod směrováním koncového bodu místo toho, aby se vygeneruje neplatný identifikátor URI.
• Okolní hodnoty (parametry trasy z aktuálního kontextu) se při generování propojení se směrováním koncového bodu automaticky nepoužít. Dříve se při generování odkazu na jinou akci (nebo stránku) nespecifikované hodnoty tras odvodí z aktuálních okolních hodnot tras. Při použití směrování koncových bodů je nutné explicitně zadat všechny parametry trasy během generování propojení.

Razor Stránky

Stránky Razor mapování se teď odehrá v rámci UseEndpoints .

Přidejte MapRazorPages , pokud aplikace používá Razor Pages. 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ává 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 přes UseMvc nebo UseMvcWithDefaultRoute v ASP.NET Core 3.0 vyžaduje explicitní výslovný souhlas uvnitř Startup.ConfigureServices . To je nutné, protože MVC musí vědět, jestli může při inicializaci spoléhat na autorizaci a middleware CORS. K dispozici je analyzátor, který vás upozorní, pokud se aplikace pokusí použít nepodporovanou konfiguraci.

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

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 je možné použít jako směrovač se směrováním koncového bodu.

Přidejte MapHealthChecks pro použití kontrol stavu se směrováním koncového bodu. Metoda MapHealthChecks přijímá argumenty podobné UseHealthChecks . Výhodou použití funkce před je možnost použít autorizaci a mít přesnější kontrolu nad MapHealthChecks UseHealthChecks odpovídajícími zásadami.

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

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 webhosting. Následující kód ukazuje vygenerované ASP.NET Core 3.0: Program

// 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 ASP.NET Core vygenerované šablonou 2.2: Program

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ůstane ve 3.0 a je typem objektu webBuilder , který je vidět v předchozím vzorové kódu. WebHostBuilder bude v budoucí verzi zastaralá a HostBuilder nahrazena .

Nejvýznamnější změnou z WebHostBuilder na je HostBuilder injektáž závislostí (DI). Při použití můžete do konstruktoru vložit pouze HostBuilder Startup následující:

• IConfiguration
• IHostEnvironment
• IWebHostEnvironment

Omezení HostBuilder diody:

• Povolte, aby se kontejner DI sesstavěl jenom jednou.
• Vyhnete se výsledným problémům s životností objektu, jako je řešení více instancí jednosměnných instancí.

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

AddAuthorization se přesunulo do jiného sestavení

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

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

Aplikace, které používají Microsoft.AspNetCore.Authorization.dll i Microsoft.AspNetCore.Authorization.Policy.dll, nejsou ovlivněny.

Aplikace, které Microsoft.AspNetCore.Authorization.Policy.dll, by měly provést jednu z následujících akcí:

• 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 části Breaking change in ) overload lives in a different assembly AddAuthorization(o => #386.

Identity UI

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

• Přidejte odkaz na balíček do Microsoft.AspNetCore. Identity . Uživatelské rozhraní.
• Aplikace, které stránky Razor nepou3/4í, musí volat MapRazorPages . Viz Razor Stránky v tomto dokumentu.
• Bootstrap 4 je výchozí rozhraní uživatelského rozhraní. Nastavte IdentityUIFrameworkVersion vlastnost projektu a změňte výchozí hodnotu. Další informace najdete v tomto GitHub .

SignalR

Klient SignalR JavaScriptu se změnil z @aspnet/signalr na @microsoft/signalr . Pokud chcete na tuto změnu reagovat, změňte odkazy vpackage.jsna soubory, příkazy a příkazy require ECMAScript. import

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

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

V Startup.ConfigureServices volejte AddJsonProtocol pro nastavení možností serializátoru.

Server:

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

Klienta:

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

Přepnout na Newtonsoft.Jszapnout

Pokud používáte funkce systému Newtonsoft.Js,které nejsou podporované v System.Text.Jsna , můžete přepnout zpět na Newtonsoft.Json . Viz použití Newtonsoft.Json v projektu ASP.NET Core 3.0 SignalR dříve v tomto článku.

Distribuované mezipaměti Redis

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

Výslovný souhlas s kompilací modulu runtime

Před ASP.NET Core verze 3.0 byla kompilace zobrazení za běhu implicitní funkcí rozhraní. Kompilace modulu runtime doplňuje kompilaci zobrazení v době sestavení. Umožňuje rozhraní kompilovat zobrazení a Razor stránky (soubory .cshtml) při úpravy souborů bez nutnosti znovu sestavovat celou aplikaci. Tato funkce podporuje scénář rychlé úpravy v integrovaném vývojovém prostředí a aktualizace prohlížeče pro zobrazení změn.

V ASP.NET Core verze 3.0 je scénář výslovného souhlasu s kompilací modulu runtime. Kompilace v době sestavení je jediným mechanismem pro kompilaci zobrazení, která je ve výchozím nastavení povolená. Modul runtime spoléhá na Visual Studio nebo dotnet-watch v Visual Studio Code při zjištění změn v souborech .cshtml znovu sestaví projekt. V Visual Studio změny souborů .cs, .cshtml nebo .razor v projektu, který se spouští (Ctrl+F5), ale nejsou laděné (F5), aktivují rekompilace projektu.

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

1. Nainstalujte Microsoft.AspNetCore.Mvc. Razor . RuntimeCompilation NuGet balíček.

2. Aktualizace Startup.ConfigureServices pro volání AddRazorRuntimeCompilation :

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

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

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

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

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

Další informace o Razor kompilaci souborů najdete v tématu Razorkompilace souborů 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ů dál fungovat. Následující podmínky vyžadují křížové zkompilování aplikace:

• Knihovna spoléhá na funkci, která má binární změnu narušuje.
• Knihovna chce využívat nové funkce ve 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>

Pomocí #ifdefs můžete ASP.NET Core rozhraní API specifických pro 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í 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

Systém ověřování v .NET Core 3.0 a novějších verzích považuje parametry, které nejsou nullable, nebo vázané vlastnosti, jako by měly [Required] atribut. Další informace najdete v atributu [Required].

Publikovat

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

Testovací server

Pro aplikace, které TestServer používají přímo s obecným hostitelem, vytvořte TestServer v souboru 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);
}

Rozbíjení změn rozhraní API

Kontrola změn, které se rušijí:

• Úplný seznam nejnovějších změn ve verzi ASP.NET Core 3.0
• Rozbíjení změn rozhraní API v oblasti antiforgery, CORS, diagnostiky, MVCa směrování Tento seznam obsahuje rozbíjení přepínačů kompatibility.
• Souhrn změn 2.2 až 3.0, které přerušování v .NET Core, ASP.NET Core a Entity Framework Core najdete v tématu Rozbíjení změn 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 na Azure App Service

Bylo dokončeno Azure App Service .NET Core. .NET Core 3.0 je k dispozici ve všech Azure App Service datacentrech.