Migrera från ASP.NET Core 2.2 till 3.0

Av Scott Addie och Rick Anderson

Den här artikeln beskriver hur du uppdaterar ett befintligt ASP.NET Core 2.2-projekt till ASP.NET Core 3.0. Det kan vara bra att skapa ett nytt ASP.NET Core 3.0-projekt för att:

• Jämför med ASP.NET Core 2.2-koden.
• Kopiera relevanta ändringar i ditt ASP.NET Core 3.0-projekt.

Förutsättningar

Uppdatera .NET Core SDK-versionen i global.json

Om din lösning förlitar sig på en global.json fil för att rikta in sig på en specifik .NET Core SDK-version uppdaterar du dess version-egenskap till 3.0-versionen som är installerad på datorn:

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

Uppdatera projektfilen

Uppdatera Målramverket

ASP.NET Core 3.0 eller senare körs endast på .NET Core. Ange Target Framework Moniker (TFM) till netcoreapp3.0:

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

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

</Project>

Ta bort föråldrade paketreferenser

Ett stort antal NuGet-paket produceras inte för ASP.NET Core 3.0. Sådana paketreferenser bör tas bort från projektfilen. Överväg följande projektfil för en ASP.NET Core 2.2-webbapp:

<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>

Den uppdaterade projektfilen för ASP.NET Core 3.0:

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

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

</Project>

Den uppdaterade ASP.NET Core 3.0-projektfilen:

• I <PropertyGroup>:

  • Uppdaterar TFM till netcoreapp3.0
  • Tar bort elementet <AspNetCoreHostingModel>. Mer information finns i In-process hosting model i det här dokumentet.

• I <ItemGroup>:

  • Microsoft.AspNetCore.App tas bort. Mer information finns i Framework-referens i det här dokumentet.
  • Microsoft.AspNetCore.Razor.Design tas bort och i följande lista över paket som inte längre produceras.

Om du vill se den fullständiga listan över paket som inte längre produceras väljer du följande expanderande lista:

Granska kritiska ändringar

Granska icke-bakåtkompatibla ändringar

Ramverksreferens

Funktioner i ASP.NET Core som var tillgängliga via ett av paketen ovan är tillgängliga som en del av det Microsoft.AspNetCore.App delade ramverket. Det delade ramverket är uppsättningen sammansättningar (.dll filer) som är installerade på datorn och innehåller en körningskomponent och ett målpaket. Mer information finns i Det delade ramverket.

• Projekt som är inriktade på Microsoft.NET.Sdk.Web SDK refererar implicit till det Microsoft.AspNetCore.App ramverket.

  Inga ytterligare referenser krävs för dessa projekt:

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

• Projekt som är inriktade på Microsoft.NET.Sdk eller Microsoft.NET.Sdk.Razor SDK bör lägga till en explicit FrameworkReference i Microsoft.AspNetCore.App:

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

Ramverksberoende versioner med Docker

Ramverksberoende versioner av konsolappar som använder ett paket som är beroende av ASP.NET Core delat ramverk kan ge följande körningsfel:

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 är det delade ramverket som innehåller ASP.NET Core-körningen och finns bara på dotnet/core/aspnet Docker-avbildningen. SDK:t 3.0 minskar storleken på ramverksberoende versioner med hjälp av ASP.NET Core genom att inte inkludera duplicerade kopior av bibliotek som är tillgängliga i det delade ramverket. Detta är en potentiell besparing på upp till 18 MB, men det kräver att ASP.NET Core-körningen finns/installeras för att köra appen.

För att avgöra om appen har ett beroende (antingen direkt eller indirekt) för det delade ASP.NET Core-ramverket, granskar du den runtimeconfig.json fil som genererades under en version/publicering av din app. Följande JSON-fil visar ett beroende av det delade ASP.NET Core-ramverket:

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

Om appen använder Docker använder du en basavbildning som innehåller ASP.NET Core 3.0. Exempel: docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0.

Lägga till paketreferenser för borttagna sammansättningar

ASP.NET Core 3.0 tar bort vissa sammansättningar som tidigare ingick i Microsoft.AspNetCore.App-paketreferensen. Om du vill visualisera vilka sammansättningar som har tagits bort jämför du de två delade ramverksmapparna. Till exempel en jämförelse av versionerna 2.2.7 och 3.0.0:

Om du vill fortsätta använda funktioner som tillhandahålls av de borttagna sammansättningarna refererar du till 3.0-versionerna av motsvarande paket:

• En mallgenererad webbapp med enskilda användarkonton kräver att följande paket läggs till:

  <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

  Mer information om hur du refererar till det databasproviderspecifika paketet finns i Database Providers.

• Identity användargränssnitt

  Stöd för Identity användargränssnitt kan läggas till genom att referera till Microsoft.AspNetCore.Identity. UI- paket.

• SPA-tjänster

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

• Autentisering: Stöd för autentiseringsflöden från tredje part är tillgängliga som NuGet-paket:

  • Facebook OAuth (Microsoft.AspNetCore.Authentication.Facebook)
  • Google OAuth (Microsoft.AspNetCore.Authentication.Google)
  • Microsoft-kontoautentisering (Microsoft.AspNetCore.Authentication.MicrosoftAccount)
  • OpenID Connect-autentisering (Microsoft.AspNetCore.Authentication.OpenIdConnect)
  • OpenID Connect-ägartoken (Microsoft.AspNetCore.Authentication.JwtBearer)
  • Twitter OAuth (Microsoft.AspNetCore.Authentication.Twitter)
  • WsFederation-autentisering (Microsoft.AspNetCore.Authentication.WsFederation)

• Stöd för formatering och innehållsförhandling för System.Net.HttpClient: NuGet-paketet Microsoft.AspNet.WebApi.Client ger användbar utökningsbarhet för System.Net.HttpClient med API:er som ReadAsAsync och PostJsonAsync. Det här paketet beror dock på Newtonsoft.Json, inte System.Text.Json. Det innebär till exempel att serialiseringsegenskapsnamn som anges av JsonPropertyNameAttribute (System.Text.Json) ignoreras. Det finns ett nyare NuGet-paket som innehåller liknande tilläggsmetoder men som använder System.Text.Json: System.Net.Http.Json.

• Razor Kompilering vid körning: Stöd för kompilering vid körning av Razor vyer och sidor ingår nu i Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

• Stöd för MVC Newtonsoft.Json (Json.NET): Stöd för att använda MVC med Newtonsoft.Json ingår nu i Microsoft.AspNetCore.Mvc.NewtonsoftJson.

Ändringar vid start

Följande bild visar de borttagna och ändrade raderna i en ASP.NET Core 2.2-Razor Pages-webbapp:

I föregående bild visas borttagen kod i rött. Den borttagna koden visar inte cookie alternativkod, som togs bort innan filerna jämfördes.

Följande bild visar de tillagda och ändrade raderna i en ASP.NET Core 3.0-Razor Pages-webbapp:

I föregående bild visas den tillagda koden i grönt. För information om följande ändringar:

• services.AddMvc till services.AddRazorPages, se MVC-tjänstregistrering i det här dokumentet.
• CompatibilityVersion, se Kompatibilitetsversion för ASP.NET Core MVC.
• IHostingEnvironment till IWebHostEnvironment, se det här GitHub-meddelandet.
• app.UseAuthorization lades till i mallarna för att visa att mellanprogrammet för orderauktorisering måste läggas till. Om appen inte använder auktorisering kan du på ett säkert sätt ta bort anropet till app.UseAuthorization.
• app.UseEndpoints, se Razor Pages eller Migrate Startup.Configure i det här dokumentet.

Stöd för Analyzer

Projekt som riktar sig mot Microsoft.NET.Sdk.Web refererar implicit till analysverktyg som tidigare levererades som en del av Microsoft.AspNetCore.Mvc.Analyzers-paketet. Inga ytterligare referenser krävs för att aktivera dessa.

Om din app använder API-analysverktyg som tidigare levererats med hjälp av Microsoft.AspNetCore.Mvc.Api.Analyzeers-paketet redigerar du projektfilen för att referera till analysverktygen som levereras som en del av .NET Core Web SDK:

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

    ...
</Project>

Razor klassbibliotek

Razor klassbiblioteksprojekt som tillhandahåller gränssnittskomponenter för MVC måste ange egenskapen AddRazorSupportForMvc i projektfilen:

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

In-process-värdmodell

Projekt som standard är pågående värdmodell i ASP.NET Core 3.0 eller senare. Du kan också ta bort egenskapen <AspNetCoreHostingModel> i projektfilen om dess värde är InProcess.

Kestrel

Konfiguration

Migrera Kestrel konfiguration till webbvärdbyggaren som tillhandahålls av 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>();
        });

Om appen skapar värden manuellt med ConfigureWebHost istället för ConfigureWebHostDefaults, anropar du UseKestrel på webbhostarebyggaren:

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();
}

Anslutningsmellanprogram ersätter anslutningskort

Anslutningskort (Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter) har tagits bort från Kestrel. Ersätt anslutningskort med anslutningsmellanprogram. Anslutningsmellanprogram liknar HTTP Middleware i ASP.NET Core-pipelinen men för anslutningar på lägre nivå. HTTPS och anslutningsloggning:

• Har flyttats från anslutningsadaptrar till mellanprogramvara.
• Dessa tilläggsmetoder fungerar som i tidigare versioner av ASP.NET Core.

Mer information finns i TlsFilterConnectionHandler-exemplet i avsnittet ListenOptions.Protocols i artikeln Kestrel.

Transportabstraktioner flyttades och offentliggjordes

Transportlagret Kestrel har exponerats som ett offentligt gränssnitt i Connections.Abstractions. Som en del av dessa uppdateringar:

• Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions och associerade typer har tagits bort.
• NoDelay flyttades från ListenOptions till transportalternativen.
• Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.Internal.SchedulingMode har tagits bort från KestrelServerOptions.

Mer information finns i följande GitHub-resurser:

• klient-/servernätverksabstraktioner (dotnet/AspNetCore #10308)
• Implementera ny abstraktion av berggrundslyssnare och formatera om Kestrel överst (dotnet/AspNetCore #10321)

Kestrel Begär trailerhuvuden

För appar som riktar sig mot tidigare versioner av ASP.NET Core:

• Kestrel lägger till HTTP/1.1 segmenterade trailerhuvuden i samlingen med begärandehuvuden.
• Släpvagnar är tillgängliga när begärandetexten har lästs till slutet.

Detta orsakar viss oro för tvetydighet mellan huvuden och släpvagnar, så släpvagnarna har flyttats till en ny samling (RequestTrailerExtensions) i 3.0.

HTTP/2-begärandetrailrar är:

• Inte tillgängligt i ASP.NET Core 2.2.
• Tillgänglig i 3.0 som RequestTrailerExtensions.

Det finns nya metoder för att begära tillägg för att få åtkomst till dessa släpvagnar. Precis som med HTTP/1.1 är trailers tillgängliga när begärandetexten har lästs till slutet.

För 3.0-versionen är följande RequestTrailerExtensions metoder tillgängliga:

• GetDeclaredTrailers: Hämtar begäran Trailer rubrik som visar vilka trailers som ska förväntas efter brödtexten.
• SupportsTrailers: Anger om begäran stöder mottagandet av trailerhuvuden.
• CheckTrailersAvailable: Kontrollerar om begäran stöder trailers och om de är tillgängliga för läsning. Den här kontrollen förutsätter inte att det finns trailers att läsa. Det kanske inte finns några trailers att läsa även om true returneras med den här metoden.
• GetTrailer: Hämtar den begärda avslutande rubriken från svaret. Kontrollera SupportsTrailers innan du anropar GetTrailer, annars kan en NotSupportedException inträffa om begäran inte stöder trailing headers.

Mer information hittar du i Placera förfråganstrailrar i en separat samling (dotnet/AspNetCore #10410).

AllowSynchronousIO inaktiverad

AllowSynchronousIO aktiverar eller inaktiverar synkrona I/O-API:er, till exempel HttpRequest.Body.Read, HttpResponse.Body.Writeoch Stream.Flush. Dessa API:er är en källa till trådsvält som leder till appkrascher. I 3.0 inaktiveras AllowSynchronousIO som standard. Mer information finns i avsnittet Synkron I/O i artikeln Kestrel.

Om synkron I/O behövs kan det aktiveras genom att konfigurera alternativet AllowSynchronousIO på den server som används (när du anropar ConfigureKestrel, till exempel om du använder Kestrel). Observera att servrar (Kestrel, HttpSys, TestServer osv.) alla har sina egna AllowSynchronousIO alternativ som inte påverkar andra servrar. Synkron I/O kan aktiveras för alla servrar per begäran med hjälp av alternativet IHttpBodyControlFeature.AllowSynchronousIO:

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

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

Om du har problem med TextWriter-implementeringar eller andra strömmar som anropar synkrona API:er i Dispose, bör du i stället anropa det nya DisposeAsync API:et.

Mer information finns i [Meddelande] AllowSynchronousIO inaktiverad på alla servrar (dotnet/AspNetCore #7644).

Utdataformateringsbuffertning

Newtonsoft.Json, XmlSerializeroch DataContractSerializer baserade utdataformaterare stöder endast synkron serialisering. För att tillåta att dessa formaterare fungerar med AllowSynchronousIO- begränsningar för servern buffrar MVC utdata från dessa formaterare innan de skrivs till disken. Som ett resultat av buffring kommer MVC att inkludera rubriken Innehållslängd när du svarar med hjälp av dessa formaterare.

System.Text.Json stöder asynkron serialisering och därför buffr inte den System.Text.Json baserade formatatorn. Överväg att använda den här formateringsfunktionen för bättre prestanda.

Om du vill inaktivera buffring kan program konfigurera SuppressOutputFormatterBuffering i sin start:

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

Observera att detta kan leda till att programmet utlöser ett körningsundantag om AllowSynchronousIO inte också har konfigurerats.

Microsoft.AspNetCore.Server.Kestrel. Https-sammansättningen har tagits bort

I ASP.NET Core 2.1 flyttades innehållet i Microsoft.AspNetCore.Server.Kestrel.Https.dll till Microsoft.AspNetCore.Server.Kestrel.Core.dll. Det här var en icke-brytande uppdatering med hjälp av TypeForwardedTo attribut. För 3.0 har den tomma Microsoft.AspNetCore.Server.Kestrel.Https.dll assembly och NuGet-paketet tagits bort.

Bibliotek som refererar till Microsoft.AspNetCore.Server.Kestrel. Https bör uppdatera ASP.NET Core-beroenden till 2.1 eller senare.

Appar och bibliotek som riktar sig till ASP.NET Core 2.1 eller senare bör ta bort alla direkta referenser till Microsoft.AspNetCore.Server.Kestrel. Https-paket.

Support för Newtonsoft.Json (Json.NET)

Som en del av arbetet med att förbättra det delade ASP.NET Core-ramverkethar Newtonsoft.Json (Json.NET) tagits bort från det delade ramverket ASP.NET Core.

JSON-standard-serialiseraren för ASP.NET Core är nu System.Text.Json, som är ny i .NET Core 3.0. Överväg att använda System.Text.Json när det är möjligt. Det är högpresterande och kräver inget ytterligare biblioteksberoende. Men eftersom System.Text.Json är nytt kanske det för närvarande saknas funktioner som din app behöver. Mer information finns i Så här migrerar du från Newtonsoft.Json till System.Text.Json.

Använda Newtonsoft.Json i ett ASP.NET Core 3.0-SignalR projekt

• Installera Microsoft.AspNetCore.SignalR. Protocols.NewtonsoftJson NuGet-paket.

• På klienten kedjar du ett AddNewtonsoftJsonProtocol-metodanrop till HubConnectionBuilder-instansen:

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

• På servern kedjar du ett AddNewtonsoftJsonProtocol-metodanrop till AddSignalR-metodanropet i Startup.ConfigureServices:

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

Använda Newtonsoft.Json i ett ASP.NET Core 3.0 MVC-projekt

• Installera Microsoft.AspNetCore.Mvc.NewtonsoftJson-paketet.

• Uppdatera Startup.ConfigureServices för att anropa AddNewtonsoftJson.

  services.AddMvc()
      .AddNewtonsoftJson();
  

  AddNewtonsoftJson är kompatibelt med de nya MVC-tjänstregistreringsmetoderna:

  • AddRazorPages
  • AddControllersWithViews
  • AddControllers

  services.AddControllers()
      .AddNewtonsoftJson();
  

  Newtonsoft.Json inställningar kan ställas in i anropet till AddNewtonsoftJson:

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

  Obs! Om metoden AddNewtonsoftJson inte är tillgänglig kontrollerar du att du har installerat Microsoft.AspNetCore.Mvc.NewtonsoftJson-paketet. Ett vanligt fel är att installera Newtonsoft.Json--paketet i stället för Microsoft.AspNetCore.Mvc.NewtonsoftJson-paketet.

Mer information finns i Lägg till Newtonsoft.Json-baserat JSON-formatstöd.

MVC-tjänstregistrering

ASP.NET Core 3.0 lägger till nya alternativ för att registrera MVC-scenarier i Startup.ConfigureServices.

Tre nya tilläggsmetoder på toppnivå som är relaterade till MVC-scenarier på IServiceCollection är tillgängliga. Mallar använder dessa nya metoder i stället för AddMvc. Men AddMvc fortsätter att fungera som i tidigare versioner.

I följande exempel läggs stöd för kontrollanter och API-relaterade funktioner, men inte vyer eller sidor. API-mallen använder den här koden:

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

I följande exempel läggs stöd för kontrollanter, API-relaterade funktioner och vyer, men inte sidor. MVC-mallen (Web Application) använder den här koden:

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

I följande exempel läggs stöd till för Razor Pages och minimalt stöd till kontroller. Webbprogrammallen använder den här koden:

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

De nya metoderna kan också kombineras. Följande exempel motsvarar att anropa AddMvc i ASP.NET Core 2.2:

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

Routningsstartkod

Om en app anropar UseMvc eller UseSignalRmigrerar du appen till Slutpunktsroutning om möjligt. För att förbättra kompatibiliteten för slutpunktsroutning med tidigare versioner av MVC har vi återställt några av de ändringar i URL-genereringen som introducerades i ASP.NET Core 2.2. Om du har problem med att använda slutpunktsroutning i 2.2 kan du förvänta dig förbättringar i ASP.NET Core 3.0 med följande undantag:

• Om appen implementerar IRouter eller ärver från Routeanvänder du DynamicRouteValuesTransformer som ersättning.
• Om appen direkt kommer åt RouteData.Routers inom MVC för att tolka URL:er kan du ersätta detta med att använda LinkParser.ParsePathByEndpointName.
  • Definiera vägen med ett vägnamn.
  • Använd LinkParser.ParsePathByEndpointName och ange det önskade routnamnet.

Slutpunktsroutning stöder samma routningsmönstersyntax och routningsmönsterredigeringsfunktioner som IRouter. Slutpunktsroutning stöder IRouteConstraint. Slutpunktsroutning stöder [Route], [HttpGet]och andra MVC-routningsattribut.

För de flesta program kräver endast Startup ändringar.

Migrera Startup.Configure

Allmänna råd:

• Lägg till UseRouting.

• Om appen anropar UseStaticFilesplacerar du UseStaticFilesföreUseRouting.

• Om appen använder funktioner för autentisering/auktorisering, till exempel AuthorizePage eller [Authorize], placerar du anropet till UseAuthentication och UseAuthorization: efter, UseRouting och UseCors, men före UseEndpoints:

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

• Ersätt UseMvc eller UseSignalR med UseEndpoints.

• Om appen använder CORS- scenarier, till exempel [EnableCors], placerar du anropet till UseCors före andra mellanprogram som använder CORS (till exempel placera UseCors före UseAuthentication, UseAuthorizationoch UseEndpoints).

• Ersätt IHostingEnvironment med IWebHostEnvironment och lägg till en using-instruktion för Microsoft.AspNetCore.Hosting-namnområdet.

• Ersätt IApplicationLifetime med IHostApplicationLifetime (Microsoft.Extensions.Hosting namnområde).

• Ersätt EnvironmentName med Environments (Microsoft.Extensions.Hosting namnområde).

Följande kod är ett exempel på Startup.Configure i en typisk ASP.NET Core 2.2-app:

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?}");
    });
}

När du har uppdaterat föregående Startup.Configure kod:

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?}");
    });
}

Hälsokontroller

Hälsokontroller använder slutpunktsdirigering med den generiska värden. I Startup.Configureanropar du MapHealthChecks på slutpunktsverktyget med slutpunkts-URL:en eller den relativa sökvägen:

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

Slutpunkter för hälsokontroller kan:

• Ange en eller flera tillåtna värdar/portar.
• Kräv auktorisering.
• Kräv CORS.

Mer information finns i Hälsokontroller i ASP.NET Core.

Vägledning för säkerhetsmellanprogram

Stöd för auktorisering och CORS är enhetligt kring middleware-metoden. Detta tillåter användning av samma mellanprogram och funktioner i dessa scenarier. Ett uppdaterat mellanprogram för auktorisering tillhandahålls i den här versionen och CORS Middleware förbättras så att det kan förstå de attribut som används av MVC-styrenheter.

CORS (Cross-Origin Resource Sharing)

Tidigare kan CORS vara svårt att konfigurera. Mellanprogram tillhandahölls för användning i vissa användningsfall, men MVC-filter var avsedda att användas utan mellanprogrammet i andra användningsfall. Med ASP.NET Core 3.0 rekommenderar vi att alla appar som kräver CORS använder CORS Middleware tillsammans med Slutpunktsroutning. UseCors kan tillhandahållas med en standardprincip och [EnableCors] och [DisableCors] attribut kan användas för att åsidosätta standardprincipen där det behövs.

I följande exempel:

• CORS är aktiverat för alla slutpunkter med den namngivna principen default.
• Klassen MyController inaktiverar CORS med attributet [DisableCors].

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseCors("default");

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

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

Auktorisering

I tidigare versioner av ASP.NET Core tillhandahölls auktoriseringsstöd via attributet [Authorize]. Mellanprogrammet för auktorisering var inte tillgängligt. I ASP.NET Core 3.0 krävs mellanprogram för auktorisering. Vi rekommenderar att du placerar ASP.NET Core Authorization Middleware (UseAuthorization) omedelbart efter UseAuthentication. Auktoriseringsmellanprogrammet kan också konfigureras med en standardprincip som kan åsidosättas.

I ASP.NET Core 3.0 eller senare anropas UseAuthorization i Startup.Configureoch följande HomeController kräver en inloggad användare:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

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

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

När du använder slutpunktsroutning rekommenderar vi att du inte konfigurerar AuthorizeFilter och i stället förlitar dig på auktoriseringsmellanprogrammet. Om appen använder en AuthorizeFilter som ett globalt filter i MVC rekommenderar vi att du omstrukturerar koden för att tillhandahålla en princip i anropet till AddAuthorization.

Den DefaultPolicy är ursprungligen konfigurerad för att kräva autentisering, så ingen ytterligare konfiguration krävs. I följande exempel markeras MVC-slutpunkter som RequireAuthorization så att alla begäranden måste auktoriseras baserat på DefaultPolicy. Men HomeController tillåter åtkomst utan att användaren loggar in i appen på grund av [AllowAnonymous]:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

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

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

Auktorisering för specifika slutpunkter

Auktorisering kan också konfigureras för specifika klasser av slutpunkter. Följande kod är ett exempel på konvertering av en MVC-app som konfigurerade en global AuthorizeFilter till en app med en specifik princip som kräver auktorisering:

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();
        });
    }
}

Principer kan också anpassas. DefaultPolicy är konfigurerad för att kräva autentisering:

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
{

Alternativt kan alla slutpunkter konfigureras för att kräva auktorisering utan [Authorize] eller RequireAuthorization genom att konfigurera en FallbackPolicy. FallbackPolicy skiljer sig från DefaultPolicy. DefaultPolicy utlöses av [Authorize] eller RequireAuthorization, medan FallbackPolicy utlöses när ingen annan princip har angetts. FallbackPolicy har konfigurerats för att tillåta begäranden utan auktorisering.

Följande exempel är detsamma som föregående DefaultPolicy exempel, men använder FallbackPolicy för att alltid kräva autentisering på alla slutpunkter förutom när [AllowAnonymous] anges:

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
{
    ...
}

Auktorisering via mellanprogram fungerar utan att ramverket har någon specifik kunskap om auktorisering. Till exempel har hälsokontroller ingen specifik kunskap om auktorisering, men hälsokontroller kan ha en konfigurerbar auktoriseringsprincip som tillämpas av mellanlagret.

Dessutom kan varje slutpunkt anpassa sina auktoriseringskrav. I följande exempel bearbetar UseAuthorization auktorisering med DefaultPolicy, men slutpunkten för /healthz hälsokontroll kräver en admin användare:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

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

Skydd implementeras för vissa scenarier. Middleware för slutpunkter kastar ett undantag om en auktorisations- eller CORS-policy utelämnas på grund av att middleware saknas. Analyzer-stöd för att ge ytterligare feedback om felkonfiguration pågår.

Anpassade auktoriseringshanterare

Om appen använder anpassade auktoriseringshanterareskickar slutpunktsroutning en annan resurstyp till hanterare än MVC. Hanterare som förväntar sig att auktoriseringshanterarkontextresursen ska vara av typen AuthorizationFilterContext (resurstypen som tillhandahålls av MVC-filter) måste uppdateras för att hantera resurser av typen RouteEndpoint (resurstypen som ges till auktoriseringshanterare via slutpunktsroutning).

MVC använder fortfarande AuthorizationFilterContext resurser, så om appen använder MVC-auktoriseringsfilter tillsammans med auktorisering för slutpunktsroutning kan det vara nödvändigt att hantera båda typerna av resurser.

SignalR

Mappning av SignalR hubbar sker nu i UseEndpoints.

Mappa varje hubb med MapHub. Precis som i tidigare versioner visas varje hubb tydligt.

I följande exempel läggs stöd för ChatHubSignalR hubben till:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

Det finns ett nytt alternativ för att kontrollera meddelandestorleksgränser från klienter. Till exempel i Startup.ConfigureServices:

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

I ASP.NET Core 2.2 kan du ange TransportMaxBufferSize och det skulle effektivt styra den maximala meddelandestorleken. I ASP.NET Core 3.0 styr det alternativet nu bara den maximala storleken innan ryggtryck observeras.

SignalR sammansättningar i delat ramverk

ASP.NET Core SignalR serversidesammansättningar installeras nu med .NET Core SDK. Mer information finns i Ta bort föråldrade paketreferenser i det här dokumentet.

MVC-styrenheter

Mappning av kontroller sker nu i UseEndpoints.

Lägg till MapControllers om appen använder attributroutning. Eftersom routning innehåller stöd för många ramverk i ASP.NET Core 3.0 eller senare kan du välja att lägga till attributroutade kontrollanter.

Ersätt följande:

• MapRoute med MapControllerRoute
• MapAreaRoute med MapAreaControllerRoute

Eftersom routning nu innehåller stöd för mer än bara MVC har terminologin ändrats så att dessa metoder tydligt anger vad de gör. Konventionella vägar som MapControllerRoute/MapAreaControllerRoute/MapDefaultControllerRoute tillämpas i den ordning som de läggs till. Placera mer specifika vägar (till exempel vägar för ett område) först.

I följande exempel:

• MapControllers lägger till stöd för attributroutade kontrollanter.
• MapAreaControllerRoute lägger till en konventionell väg för styrenheter i ett område.
• MapControllerRoute lägger till en konventionell väg för kontrollanter.

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?}");
    });
}

Async-suffixborttagning från kontrollantens åtgärdsnamn

I ASP.NET Core 3.0 tar ASP.NET Core MVC bort Async suffix från kontrollantens åtgärdsnamn. Både routning och länkgenerering påverkas av den här nya standardinställningen. Till exempel:

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

Före ASP.NET Core 3.0:

• Den föregående åtgärden kan nås på Products/ListAsync route.

• Länkgenerering krävs för att ange Async-suffixet. Till exempel:

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

I ASP.NET Core 3.0:

• Föregående åtgärd kan nås på följande rutt Produkter/Lista.

• Länkgenerering kräver inte att Async suffix anges. Till exempel:

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

Den här ändringen påverkar inte namn som anges med attributet [ActionName]. Standardbeteendet kan inaktiveras med följande kod i Startup.ConfigureServices:

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

Ändringar i länkgenerering

Det finns vissa skillnader i länkgenerering (till exempel med Url.Link och liknande API:er). Dessa inkluderar:

• När du använder slutpunktsroutning bevaras som standard inte nödvändigtvis höljet för routningsparametrar i genererade URI:er. Det här beteendet kan styras med IOutboundParameterTransformer-gränssnittet.
• Om du genererar en URI för en ogiltig väg (en kontrollant/åtgärd eller sida som inte finns) skapas en tom sträng under slutpunktsroutning i stället för att skapa en ogiltig URI.
• Omgivande värden (vägparametrar från den aktuella kontexten) används inte automatiskt i länkgenerering med slutpunktsroutning. Tidigare, när du genererar en länk till en annan åtgärd (eller sida), skulle ospecificerade vägvärden härledas från aktuella dirigerar omgivande värden. När du använder slutpunktsroutning måste alla routningsparametrar anges explicit under länkgenereringen.

Razor sidor

Kartläggning av Razor-sidorna sker nu i UseEndpoints.

Lägg till MapRazorPages om appen använder Razor Pages. Eftersom Slutpunktsroutning innehåller stöd för många ramverk behöver man nu välja att lägga till Razor Pages.

I följande Startup.Configure metod lägger MapRazorPages till stöd för Razor Pages:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

Använda MVC utan slutpunktsroutning

Användning av MVC via UseMvc eller UseMvcWithDefaultRoute i ASP.NET Core 3.0 kräver ett uttryckligt deltagande i Startup.ConfigureServices. Detta krävs eftersom MVC måste veta om det kan förlita sig på auktoriseringen och CORS Middleware under initieringen. En analysator tillhandahålls som varnar om appen försöker använda en konfiguration som inte stöds.

Om appen kräver stöd för äldre IRouter inaktiverar du EnableEndpointRouting med någon av följande metoder i 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);

Hälsokontroller

Hälsokontroller kan användas som en router-ware med slutpunktsdirigering.

Lägg till MapHealthChecks för att använda hälsokontroller med slutpunktsroutning. Metoden MapHealthChecks accepterar argument som liknar UseHealthChecks. Fördelen med att använda MapHealthChecks över UseHealthChecks är möjligheten att tillämpa auktorisering och få större detaljerad kontroll över matchningsprincipen.

I följande exempel anropas MapHealthChecks för en slutpunkt för hälsokontroll i /healthz:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

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

HostBuilder ersätter WebHostBuilder

Mallarna ASP.NET Core 3.0 använder generic host. Tidigare versioner använde Web Host. Följande kod visar mallen ASP.NET Core 3.0 som genererats Program klass:

// 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>();
            });
}

Följande kod visar ASP.NET Core 2.2-mallgenererad Program-klass:

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 finns kvar i 3.0 och är den typ av webBuilder som visas i föregående kodexempel. WebHostBuilder kommer att bli inaktuell i en framtida version och ersättas av HostBuilder.

Den mest betydande förändringen från WebHostBuilder till HostBuilder är i beroendeinjektion (DI). När du använder HostBuilderkan du bara mata in följande i Startup:s konstruktor:

• IConfiguration
• IHostEnvironment
• IWebHostEnvironment

Begränsningarna för HostBuilder DI:

• Aktivera DI-containern så att den bara skapas en gång.
• Undviker problem med objektlivslängd som uppstår vid hantering av flera instanser av singletons.

Mer information finns i Undvika starttjänstinmatning i ASP.NET Core 3.

AddAuthorization har flyttats till en annan sammansättning

Metoderna ASP.NET Core 2.2 och lägre AddAuthorization i Microsoft.AspNetCore.Authorization.dll:

• Det har bytt namn till AddAuthorizationCore.
• Har flyttats till Microsoft.AspNetCore.Authorization.Policy.dll.

Appar som använder både Microsoft.AspNetCore.Authorization.dll och Microsoft.AspNetCore.Authorization.Policy.dll påverkas inte.

Appar som inte använder Microsoft.AspNetCore.Authorization.Policy.dll bör göra något av följande:

• Lägg till en referens till Microsoft.AspNetCore.Authorization.Policy.dll. Den här metoden fungerar för de flesta appar och är allt som krävs.
• Växla till att använda AddAuthorizationCore

För mer information, se "Ändring av brott" i AddAuthorization(o =>) överlagringen finns i en annan sammansättning #386.

Identity användargränssnitt

Identity uppdateringar av användargränssnittet för ASP.NET Core 3.0:

• Lägg till en paketreferens till Microsoft.AspNetCore.Identity.UI.
• Appar som inte använder Razor Pages måste anropa MapRazorPages. se Razor sidor i det här dokumentet.
• Bootstrap 4 är standardramverket för användargränssnittet. Ange en IdentityUIFrameworkVersion projektegenskap för att ändra standardvärdet. Mer information finns i det här GitHub-meddelandet.

SignalR

JavaScript-klienten för SignalR har ändrats från @aspnet/signalr till @microsoft/signalr. Om du vill reagera på den här ändringen ändrar du referenserna i package.json-filer, require-instruktioner och ECMAScript-import-instruktioner.

System.Text.Json är standardprotokollet

System.Text.Json är nu standardprotokollet för hubb som används av både klienten och servern.

I Startup.ConfigureServicesanropar du AddJsonProtocol för att ange serialiseraralternativ.

Server:

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

Klient:

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

Växla till Newtonsoft.Json

Om du använder funktioner i Newtonsoft.Json som inte stöds i System.Text.Jsonkan du växla tillbaka till Newtonsoft.Json. Se använda Newtonsoft.Json i ett SignalR ASP.NET Core 3.0-projekt tidigare i den här artikeln.

Redis-distribuerade cacheminnen

Microsoft.Extensions.Caching.Redis-paketet är inte tillgängligt för ASP.NET Core 3.0 eller senare appar. Ersätt paketreferensen med Microsoft.Extensions.Caching.StackExchangeRedis. Mer information finns i distribuerad cachelagring i ASP.NET Core.

Anmäl dig till runtime-kompilering

Innan ASP.NET Core 3.0 var körningskompilering av vyer en implicit funktion i ramverket. Runtime-kompilering kompletterar kompilering av vyer i byggtid. Det gör att ramverket kan kompilera Razor vyer och sidor (.cshtml filer) när filerna ändras, utan att behöva återskapa hela appen. Den här funktionen stöder scenariot att göra en snabb redigering i IDE och uppdatera webbläsaren för att visa ändringarna.

I ASP.NET Core 3.0 är körningskompilering ett opt-in-scenario. Byggtidskompilering är den enda mekanismen för vykompilering som är aktiverat som standard. Körmiljön förlitar sig på Visual Studio eller dotnet-watch i Visual Studio Code för att återskapa projektet när den upptäcker ändringar i .cshtml filerna. I Visual Studio leder ändringar i .cs, .cshtmleller .razor-filer i projektet som körs (Ctrl+F5), men inte debuggas (F5), till omkompilering av projektet.

Så här aktiverar du körningskompilering i ditt ASP.NET Core 3.0-projekt:

1. Installera Microsoft.AspNetCore.Mvc.Razor. RuntimeCompilation NuGet-paket.

2. Uppdatera Startup.ConfigureServices för att anropa AddRazorRuntimeCompilation:

   Använd följande kod för ASP.NET Core MVC:

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

   Använd följande kod för ASP.NET Core Razor Pages:

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

Exemplet på https://github.com/aspnet/samples/tree/main/samples/aspnetcore/mvc/runtimecompilation visar hur körningskompilering kan aktiveras villkorligt i utvecklingsmiljöer.

Mer information om Razor filkompilering finns i Razor filkompilering i ASP.NET Core.

Migrera bibliotek via flera mål

Bibliotek behöver ofta stöd för flera versioner av ASP.NET Core. De flesta bibliotek som kompilerats mot tidigare versioner av ASP.NET Core bör fortsätta att fungera utan problem. Följande villkor kräver att appen korskompileras:

• Biblioteket förlitar sig på en funktion som har en binär icke-bakåtkompatibel ändring.
• Biblioteket vill dra nytta av nya funktioner i ASP.NET Core 3.0.

Till exempel:

<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>

Använd #ifdefs för att aktivera ASP.NET Core 3.0-specifika API:er:

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

Mer information om hur du använder ASP.NET Core-API:er i ett klassbibliotek finns i Använda ASP.NET Core-API:er i ett klassbibliotek.

Diverse ändringar

Valideringssystemet i .NET Core 3.0 eller senare behandlar icke-nullbara parametrar eller bundna egenskaper som om de hade ett [Required] attribut. Mer information finns i attributet [Krävs] .

Publicera

Ta bort mapparna bin och obj i projektkatalogen.

Testserver

För appar som använder TestServer direkt med Generic Hostskapar du TestServer på en IWebHostBuilder i 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);
}

Brytande förändringar

Använd artiklarna i Icke-bakåtkompatibla ändringar i .NET för att hitta icke-bakåtkompatibla ändringar som kan gälla när du uppgraderar en app till en nyare version av .NET.

Mer information finns i följande resurser:

• Fullständig lista över icke-bakåtkompatibla ändringar i ASP.NET Core 3.0-versionen
• Icke-bakåtkompatibla API-ändringar i Antiforgery, CORS, Diagnostik, MVC och routning. Den här listan innehåller störande ändringar för kompatibilitetsinställningar.

Slutpunktsroutning med 'fångar alla'-parametern

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 på Azure App Service

Distributionen av .NET Core till Azure App Service är klar. .NET Core 3.0 är tillgängligt i alla Azure App Service-datacenter.

ASP.NET Core Module (ANCM)

Om ASP.NET Core Module (ANCM) inte var en vald komponent när Visual Studio installerades eller om en tidigare version av ANCM installerades på systemet laddar du ned den senaste .NET Core Hosting Bundle Installer (direkt nedladdning) och kör installationsprogrammet. Mer information finns i Hosting Bundle.