Eseguire la migrazione da ASP.NET Core 3.1 a 6.0

  • Articolo
  • 5 minuti per la lettura

Questo articolo illustra come aggiornare un progetto esistente ASP.NET Core 3.1 a ASP.NET Core 6.0. Per eseguire l'aggiornamento da ASP.NET Core 5.0 a 6.0, vedere Eseguire la migrazione da ASP.NET Core 5.0 a 6.0.

Prerequisiti

Aggiornare la versione di .NET SDK in global.json

Se si fa affidamento su un global.json file per indirizzare una versione specifica di .NET SDK, aggiornare la version proprietà alla versione di .NET 6.0 SDK installata. Ad esempio:

{
  "sdk": {
-    "version": "3.1.200"
+    "version": "6.0.100"
  }
}

Aggiornare il framework di destinazione

Aggiornare il moniker (TFM) del file di progetto a net6.0:

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

  <PropertyGroup>
-    <TargetFramework>netcoreapp3.1</TargetFramework>
+    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

</Project>

Aggiornare i riferimenti del pacchetto

Nel file di progetto aggiornare ogni Microsoft.AspNetCore.*attributo , Microsoft.EntityFrameworkCore.*, Microsoft.Extensions.*e System.Net.Http.Json di riferimento Version al pacchetto a 6.0.0 o versione successiva. Ad esempio:

<ItemGroup>
-    <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="3.1.6" />
-    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="3.1.6" />
-    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="3.1.6" />
-    <PackageReference Include="System.Net.Http.Json" Version="3.2.1" />
+    <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="6.0.0" />
+    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.0" />
+    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="6.0.0" />
+    <PackageReference Include="System.Net.Http.Json" Version="6.0.0" />
</ItemGroup>

Eliminare bin e obj cartelle

Potrebbe essere necessario eliminare le bin cartelle e obj . Eseguire dotnet nuget locals --clear all per cancellare la cache dei pacchetti NuGet.

Modello di hosting minimo

I modelli di ASP.NET Core generano codice usando il nuovo modello di hosting minimo. Il modello di hosting minimo unifica Startup.cs e Program.cs in un singolo Program.cs file. ConfigureServices e Configure non vengono più usati. Le app che eseguono la migrazione da ASP.NET Core 3.1 a 6.0 non devono usare il modello di hosting minimo, usando Startup e l'host generico usato dai modelli ASP.NET Core 3.1 è completamente supportato.

Per usare Startup con il nuovo modello di hosting minimo, vedere Usare Startup con il nuovo modello di hosting minimo.

Per eseguire la migrazione al nuovo modello di hosting minimo usando il modello seguente usato dai modelli ASP.NET Core 6.0, vedere Esempi di codice migrati al nuovo modello di hosting minimo in ASP.NET Core 6.0 e Migrate da ASP.NET Core 5.0 a 6.0

Aggiornare Razor le librerie di classi (RCLs)

Eseguire la migrazione Razor delle librerie di classi (RCL) per sfruttare le nuove API o le funzionalità introdotte come parte di ASP.NET Core 6.0.

Per aggiornare un RCL destinato ai componenti:

  1. Aggiornare le proprietà seguenti nel file di progetto:

    <Project Sdk="Microsoft.NET.Sdk.Razor">
  <PropertyGroup>
-     <TargetFramework>netstandard2.0</TargetFramework>
-     <RazorLangVersion>3.0</RazorLangVersion>
+     <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  2. Aggiornare altri pacchetti alle versioni più recenti. Le versioni più recenti sono disponibili in NuGet.org.

Per aggiornare un oggetto RCL destinato a MVC, aggiornare le proprietà seguenti nel file di progetto:

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

  <PropertyGroup>
-    <TargetFramework>netcoreapp3.1</TargetFramework>
+    <TargetFramework>net6.0</TargetFramework>
    <AddRazorSupportForMvc>true</AddRazorSupportForMvc>
  </PropertyGroup>

Blazor

Per adottare tutte le funzionalità 5.0 e le funzionalità 6.0 per Blazor le app, è consigliabile eseguire il processo seguente:

  • Creare un nuovo progetto 6.0 Blazor da uno dei modelli di Blazor progetto. Per altre informazioni, vedere Strumenti per ASP.NET Core Blazor.
  • Spostare i componenti e il codice dell'app nell'app 6.0 che apporta modifiche per adottare le nuove funzionalità 5.0 e 6.0.

Aggiornare le immagini Docker

Per le app che usano Docker, aggiornare le istruzioni e gli script DockerfileFROM . Usare un'immagine di base che include il runtime di ASP.NET Core 6.0. Prendere in considerazione la differenza di comando seguente docker pull tra ASP.NET Core 3.1 e 6.0:

- docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1
+ docker pull mcr.microsoft.com/dotnet/aspnet:6.0

Come parte del passaggio a ".NET" come nome del prodotto, le immagini Docker sono state spostate dai mcr.microsoft.com/dotnet/core repository a mcr.microsoft.com/dotnet. Per altre informazioni, vedere .NET 5.0 - Docker Repo Name Change (dotnet/dotnet-docker #1939).

Modifiche all'associazione dei modelli in ASP.NET Core MVC e Razor Pages

DateTime i valori sono associati a modelli come orari UTC

In ASP.NET Core 3.1 e versioni precedenti, DateTime i valori sono associati a modelli come ora locale, dove il fuso orario è stato determinato dal server. DateTime i valori associati dalla formattazione di input (JSON) e DateTimeOffset i valori sono associati come fuso orario UTC.

In ASP.NET Core 5.0 e versioni successive, l'associazione di modelli associa DateTime in modo coerente i valori al fuso orario UTC.

Per conservare il comportamento precedente, rimuovere l'oggetto DateTimeModelBinderProvider in Startup.ConfigureServices:

services.AddControllersWithViews(options =>
    options.ModelBinderProviders.RemoveType<DateTimeModelBinderProvider>());

ComplexObjectModelBinderProvider \ ComplexObjectModelBinder Sostituire ComplexTypeModelBinderProvider \ ComplexTypeModelBinder

Per aggiungere il supporto per i tipi di record C# 9 di binding del modello, è ComplexTypeModelBinderProvider :

  • Annotato come obsoleto.
  • Non più registrato per impostazione predefinita.

Le app che si basano sulla presenza dell'oggetto ComplexTypeModelBinderProviderModelBinderProviders nella raccolta devono fare riferimento al nuovo provider di binding:

- var complexModelBinderProvider = options.ModelBinderProviders.OfType<ComplexTypeModelBinderProvider>();
+ var complexModelBinderProvider = options.ModelBinderProviders.OfType<ComplexObjectModelBinderProvider>();

UseDatabaseErrorPage Obsoleto

I modelli ASP.NET Core 3.1 che includono un'opzione per singoli account utente generano una chiamata a UseDatabaseErrorPage. UseDatabaseErrorPage è ora obsoleto e deve essere sostituito con una combinazione di AddDatabaseDeveloperPageExceptionFilter e UseMigrationsEndPoint, come illustrato nel codice seguente:

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

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

Per altre informazioni, vedere Obsoleting DatabaseErrorPage middleware (dotnet/aspnetcore #24987).

modulo ASP.NET Core (ANCM)

Se il modulo di ASP.NET Core (ANCM) non era un componente selezionato quando Visual Studio è stato installato o se una versione precedente di ANCM è stata installata nel sistema, scaricare il programma di installazione più recente del pacchetto di hosting .NET Core (download diretto) ed eseguire il programma di installazione. Per altre informazioni, vedere Bundle di hosting.

Modifica del nome dell'applicazione

In .NET 6 normalizzare WebApplicationBuilder il percorso radice del contenuto da terminare con un DirectorySeparatorCharoggetto . La maggior parte delle app che eseguono la migrazione da HostBuilder o WebHostBuilder non avrà lo stesso nome dell'app perché non sono normalizzate. Per altre informazioni, vedere SetApplicationName

Esaminare le modifiche di rilievo

Vedere le risorse seguenti: