Migración de ASP.NET Core 2.1 a 2.2
Por Scott Addie
En este artículo se explica cómo actualizar un proyecto ASP.NET Core 2.1 a ASP.NET Core 2.2.
Requisitos previos
- Visual Studio 2019 con la carga de trabajo ASP.NET y desarrollo web
- .NET Core SDK 2.2 o posterior
Advertencia
Si usa Visual Studio 2017, consulte dotnet/sdk problema #3124 para información sobre las versiones del SDK de .NET Core que no funcionan con Visual Studio.
Actualización del moniker de la plataforma de destino (TFM)
Los proyectos que tienen como destino .NET Core deben usar el TFM de una versión mayor o igual que .NET Core 2.2. En el archivo de proyecto, actualice <TargetFramework> el texto interno del nodo con netcoreapp2.2 :
<TargetFramework>netcoreapp2.2</TargetFramework>
Los proyectos que .NET Framework pueden seguir usando el TFM de una versión mayor o igual que .NET Framework 4.6.1:
<TargetFramework>net461</TargetFramework>
Adopción del modelo de hospedaje en proceso de IIS
Para adoptar el modelo de hospedaje en proceso para IIS,agregue la propiedad con un <AspNetCoreHostingModel> valor de a en el archivo del InProcess <PropertyGroup> proyecto:
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
El modelo de hospedaje en proceso no se admite para ASP.NET Core aplicaciones que tienen como destino .NET Framework.
Para más información, consulte Módulo ASP.NET Core.
Actualización de un archivo web.config personalizado
Para los proyectos que usan un archivo web.config personalizado en la raíz del proyecto para generar su archivo de web.config publicado:
- En la
<handlers>entrada que agrega el ASP.NET Core Module ( ), cambie el valor del atributo de aname="aspNetCore"modulesAspNetCoreModuleAspNetCoreModuleV2. - En el
<aspNetCore>elemento , agregue el atributo de modelo de hospedaje (hostingModel="InProcess").
Para obtener más información y archivosweb.config ejemplo, vea Módulo ASP.NET Core .
Actualización de las referencias del paquete
Si el destino es .NET Core, quite el atributo de la referencia de metapaquete Version en el archivo del proyecto. La inclusión Version de un atributo da como resultado la advertencia siguiente:
A PackageReference to 'Microsoft.AspNetCore.App' specified a Version of `2.2.0`. Specifying the version of this package is not recommended. For more information, see https://aka.ms/sdkimplicitrefs
Para más información, consulte Metapaquete Microsoft.AspNetCore.App para ASP.NET Core.
La referencia del metapaquete debe ser similar al nodo <PackageReference /> siguiente:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
Si el destino .NET Framework, actualice el atributo de cada referencia de paquete a Version 2.2.0 o posterior. Estas son las referencias de paquete de un proyecto ASP.NET Core 2.2 que tiene como destino .NET Framework:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.CookiePolicy" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.HttpsPolicy" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />
</ItemGroup>
Si hace referencia a Microsoft.AspNetCore. Razor . Paquete de diseño, actualice Version su atributo a 2.2.0 o posterior. Si no lo hace, se producirá el siguiente error:
Detected package downgrade: Microsoft.AspNetCore.Razor.Design from 2.2.0 to 2.1.2. Reference the package directly from the project to select a different version.
Actualización de la versión del SDK de .NET Core en global.json
Si la solución se basa en un archivo global.js para tener como destino una versión de SDK de .NET Core específica, actualice su propiedad a la version versión 2.2 instalada en el equipo:
{
"sdk": {
"version": "2.2.100"
}
}
Actualización de la configuración de inicio
Si usa Visual Studio Code, actualice el archivo de configuración de inicio del proyecto (.vscode/launch.jsen). La program ruta de acceso debe hacer referencia al nuevo TFM:
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (web)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceFolder}/bin/Debug/netcoreapp2.2/test-app.dll",
"args": [],
"cwd": "${workspaceFolder}",
"stopAtEntry": false,
"internalConsoleOptions": "openOnSessionStart",
"launchBrowser": {
"enabled": true,
"args": "${auto-detect-url}",
"windows": {
"command": "cmd.exe",
"args": "/C start ${auto-detect-url}"
},
"osx": {
"command": "open"
},
"linux": {
"command": "xdg-open"
}
},
"env": {
"ASPNETCORE_ENVIRONMENT": "Development"
},
"sourceFileMap": {
"/Views": "${workspaceFolder}/Views"
}
},
{
"name": ".NET Core Attach",
"type": "coreclr",
"request": "attach",
"processId": "${command:pickProcess}"
}
]
}
Actualización de Kestrel la configuración
Si la aplicación llama a mediante una llamada al método UseKestrel CreateDefaultBuilder CreateWebHostBuilder de la clase , llame a para configurar el servidor en lugar de para evitar Program ConfigureKestrel Kestrel UseKestrel conflictos con el modelo de hospedaje en proceso de IIS :
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureKestrel((context, options) =>
{
// Set properties and call methods on options
});
Si la aplicación no llama a CreateDefaultBuilder y compila el host manualmente en la clase , llame a antes de Program UseKestrel llamar a ConfigureKestrel :
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseKestrel()
.UseIISIntegration()
.UseStartup<Startup>()
.ConfigureKestrel((context, options) =>
{
// Set properties and call methods on options
})
.Build();
host.Run();
}
Para más información, consulte Implementación del servidor web Kestrel en ASP.NET Core.
Actualización de la versión de compatibilidad
Actualice la versión de compatibilidad en Startup.ConfigureServices a Version_2_2 :
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
Actualización de la directiva de CORS
En ASP.NET Core 2.2, el middleware cors responde con un origen comodín ( ) si una directiva permite cualquier origen y * permite credenciales. Las credenciales no se admiten cuando se especifica un origen comodín ( ) y los exploradores * no permitirán la solicitud cors. Para obtener más información, incluidas las opciones para corregir el problema en el cliente, vea la documentación web de MDN.
Para corregir este problema en el servidor, lleve a cabo una de las siguientes acciones:
- Modifique la directiva de CORS para que ya no permita credenciales. Es decir, quite la llamada a AllowCredentials al configurar la directiva.
- Si se requieren credenciales para que la solicitud de CORS se haga correctamente, modifique la directiva para especificar los hosts permitidos. Por ejemplo, use
builder.WithOrigins("https://api.example1.com", "https://example2.com")en lugar de usar AllowAnyOrigin .
Actualización de imágenes de Docker
En la tabla siguiente se muestran los cambios en la etiqueta de imagen de Docker:
| 2.1 | 2.2 |
|---|---|
microsoft/dotnet:2.1-aspnetcore-runtime |
mcr.microsoft.com/dotnet/core/aspnet:2.2 |
microsoft/dotnet:2.1-sdk |
mcr.microsoft.com/dotnet/core/sdk:2.2 |
Cambie las líneas del Dockerfile para usar las nuevas etiquetas de imagen de la columna FROM 2.2 de la tabla anterior.
Compilación manual en Visual Studio al usar el hospedaje en proceso de IIS
Visual Studio de compilación automática en la experiencia de solicitud del explorador no funciona con el modelo de hospedaje en proceso de IIS. Debe recompilar manualmente el proyecto cuando se usa el hospedaje en proceso. Se prevén mejoras en esta experiencia para una futura versión de Visual Studio.
Actualización del código de registro
El código de configuración de registro recomendado no cambió de 2.1 a 2.2, pero algunos patrones de codificación 1.x que todavía funcionaban en la versión 2.1 ya no funcionan en la versión 2.2.
Si la aplicación realiza la inicialización, el filtrado y la carga de configuración del proveedor de registro en la Startup clase , mueva ese código a Program.Main :
Inicialización del proveedor:
Ejemplo 1.x:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(); }Ejemplo 2.2:
public static void Main(string[] args) { var webHost = new WebHostBuilder() // ... .ConfigureLogging((hostingContext, logging) => { logging.AddConsole(); }) // ... }Filtrado:
Ejemplo 1.x:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(LogLevel.Information); // or loggerFactory.AddConsole((category, level) => category == "A" || level == LogLevel.Critical); }Ejemplo 2.2:
public static void Main(string[] args) { var webHost = new WebHostBuilder() // ... .ConfigureLogging((hostingContext, logging) => { logging.AddConsole() .AddFilter<ConsoleLoggerProvider> (category: null, level: LogLevel.Information) // or .AddFilter<ConsoleLoggerProvider> ((category, level) => category == "A" || level == LogLevel.Critical) ); }) // ... }Carga de configuración:
Ejemplo 1.x:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(Configuration); }Ejemplo 2.2:
public static void Main(string[] args) { var webHost = new WebHostBuilder() // ... .ConfigureLogging((hostingContext, logging) => { logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging")); logging.AddConsole(); }) // ... }
Para obtener más información, vea Registros en .NET Core y ASP.NET Core.