Migración de ASP.NET Core 3.1 a 6.0

En este artículo se explica cómo actualizar un proyecto de ASP.NET Core 3.1 existente a ASP.NET Core 6.0. Para actualizar de ASP.NET Core 5.0 a 6.0, consulte Migración de ASP.NET Core 5.0 a 6.0.

Requisitos previos

Actualización de la versión del SDK de .NET en global.json

Si confía en un archivo para tener como global.json destino una versión específica del SDK de .NET, actualice la version propiedad a la versión del SDK de .NET 6.0 instalada. Por ejemplo:

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

Actualización de la plataforma de destino

Actualice el moniker de la plataforma de destino (TFM) del archivo de proyecto a net6.0:

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

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

</Project>

Actualización de las referencias del paquete

En el archivo de proyecto, actualice cada Microsoft.AspNetCore.*atributo de referencia Version de paquete , Microsoft.EntityFrameworkCore.*Microsoft.Extensions.*, y System.Net.Http.Json a la versión 6.0.0 o posterior. Por ejemplo:

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

Eliminación bin y obj carpetas

Es posible que tenga que eliminar las bin carpetas y obj . Ejecute dotnet nuget locals --clear all para borrar la memoria caché del paquete NuGet.

Modelo de hospedaje mínimo

Las plantillas de ASP.NET Core generan código con el nuevo modelo de hospedaje mínimo. El modelo de hospedaje mínimo unifica Startup.cs y Program.cs en un único Program.cs archivo. ConfigureServices y Configure ya no se usan. Las aplicaciones que migran de ASP.NET Core 3.1 a 6.0 no necesitan usar el modelo de hospedaje mínimo, y Startup el host genérico usado por las plantillas de ASP.NET Core 3.1 es totalmente compatible.

Para usarlo Startup con el nuevo modelo de hospedaje mínimo, consulte Uso del inicio con el nuevo modelo de hospedaje mínimo.

Para migrar al nuevo modelo de hospedaje mínimo con el siguiente patrón usado por las plantillas de ASP.NET Core 6.0, consulte Ejemplos de código migrados al nuevo modelo de hospedaje mínimo en ASP.NET Core 6.0 y Migración de ASP.NET Core 5.0 a 6.0.

Actualizar Razor bibliotecas de clases (RCL)

Migre Razor las bibliotecas de clases (RCL) para aprovechar las nuevas API o características que se presentan como parte de ASP.NET Core 6.0.

Para actualizar una RCL destinada a los componentes:

  1. Actualice las siguientes propiedades en el archivo del proyecto:

    <Project Sdk="Microsoft.NET.Sdk.Razor">
      <PropertyGroup>
    -     <TargetFramework>netstandard2.0</TargetFramework>
    -     <RazorLangVersion>3.0</RazorLangVersion>
    +     <TargetFramework>net6.0</TargetFramework>
      </PropertyGroup>
    
  2. Actualice otros paquetes a sus versiones más recientes. Las versiones más recientes se pueden encontrar en NuGet.org.

Para actualizar una RCL dirigida a MVC, actualice las siguientes propiedades en el archivo del proyecto:

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

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

Blazor

Para adoptar todas las características 5.0 y 6.0 para Blazor las aplicaciones, se recomienda el siguiente proceso:

  • Cree un nuevo proyecto 6.0 Blazor a partir de una de las Blazor plantillas de proyecto. Para más información, vea Herramientas para ASP.NET Core Blazor.
  • Mueva los componentes y el código de la aplicación a la aplicación 6.0 realizando modificaciones para adoptar las nuevas características 5.0 y 6.0.

Actualización de imágenes de Docker

En el caso de las aplicaciones que usan Docker, actualice las instrucciones y scripts de DockerfileFROM . Use una imagen base que incluya el entorno de ejecución de ASP.NET Core 6.0. Tenga en cuenta la siguiente docker pull diferencia de comandos entre ASP.NET Core 3.1 y 6.0:

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

Como parte del traslado a ".NET" como nombre del producto, las imágenes de Docker se movieron de los mcr.microsoft.com/dotnet/core repositorios a mcr.microsoft.com/dotnet. Para obtener más información, vea .NET 5.0: cambio de nombre del repositorio de Docker (dotnet/dotnet-docker #1939).

Cambios de enlace de modelos en ASP.NET Core MVC y Razor Pages

DateTime los valores están enlazados al modelo como horas UTC

En ASP.NET Core 3.1 y versiones anteriores, DateTime los valores estaban enlazados al modelo como hora local, donde el servidor determinó la zona horaria. DateTime los valores enlazados del formato de entrada (JSON) y DateTimeOffset los valores se enlazaron como zonas horarias UTC.

En ASP.NET Core 5.0 y versiones posteriores, el enlace de modelos enlaza de forma coherente los DateTime valores con la zona horaria UTC.

Para conservar el comportamiento anterior, quite en DateTimeModelBinderProviderStartup.ConfigureServices:

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

ComplexObjectModelBinderProvider \ ComplexObjectModelBinder Reemplazar ComplexTypeModelBinderProvider \ ComplexTypeModelBinder

Para agregar compatibilidad con los tipos de registro C# 9 de enlace de modelos, es ComplexTypeModelBinderProvider :

  • Anotado como obsoleto.
  • Ya no está registrado de forma predeterminada.

Las aplicaciones que dependen de la presencia de ComplexTypeModelBinderProvider en la ModelBinderProviders colección deben hacer referencia al nuevo proveedor de enlazador:

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

UseDatabaseErrorPage Obsoleto

Las plantillas de ASP.NET Core 3.1 que incluyen una opción para las cuentas de usuario individuales generan una llamada a UseDatabaseErrorPage. UseDatabaseErrorPage ahora está obsoleto y debe reemplazarse por una combinación de AddDatabaseDeveloperPageExceptionFilter y UseMigrationsEndPoint, como se muestra en el código siguiente:

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

Para obtener más información, vea Obsoleting DatabaseErrorPage middleware (dotnet/aspnetcore #24987).

Módulo ASP.NET Core (ANCM)

Si el módulo de ASP.NET Core (ANCM) no era un componente seleccionado cuando Se instaló Visual Studio o si se instaló una versión anterior de ANCM en el sistema, descargue el instalador de agrupación de hospedaje de .NET Core más reciente (descarga directa) y ejecute el instalador. Para obtener más información, vea Hospedaje de lote.

Cambio del nombre de la aplicación

En .NET 6, WebApplicationBuilder normaliza la ruta de acceso raíz del contenido para finalizar con .DirectorySeparatorChar La mayoría de las aplicaciones que se migran desde HostBuilder o WebHostBuilder no tendrán el mismo nombre de aplicación porque no se normalizan. Para obtener más información, consulte SetApplicationName.

Revisión de los cambios importantes

Consulte los siguientes recursos: