Migrando aplicaciones de .Net Core Versión 2.2 a 3.1
21 ene.El actual desarrollo acelerado de la tecnología en todos los campos de la sociedad es un fenómeno que nos está afectando en la forma en la cual vivimos y nos comportamos hoy día, el desarrollo de software en particular tampoco se escapa de este desarrollo acelerado y la posibilidad de tener marcos de desarrollo que se vuelven obsoletos en el corto tiempo.
De los marcos de trabajo más estables y utilizado en el contexto de desarrollo de software tenemos aquellos desarrollados por Microsoft, que en su inicio fue una respuesta a la competencia con algunas tecnologías ya maduras como Java y que eventualmente lo conocemos como .Net Framework, con un conjunto de librerías que permitían el desarrollo de aplicaciones de escritorio y desarrollo web bajo aplicaciones con el marco de trabajo ASP.NET, o mejor conocido como ASP Puro.
La evolución de dicho marco de trabajo trajo en paralelo el crecimiento del entorno de desarrollo con la herramienta Visual Studio que con el paso del tiempo a agregado una serie de tecnologías que son un toolkit para el desarrollador como lo son Windows Forms, ASP .NET, WCF, WPF, Entity Framework, ASP .NET MVC, ASP .NET WebPages, WebApi, SignalR; y que ayudan a solucionar diferentes problemas que normalmente el desarrollador afronta.
La evolución de .Net Framework, aunque si bien al inicio del Framework no fue tan acelerada, ha convergido actualmente en un cambio en el paradigma, este paso final resultó el nuevo marco de trabajo de Microsoft llamado .Net Core en donde como novedad que propone como un gran cambio la posibilidad de desarrollar aplicaciones Multiplataforma y Open Source.
Entendiendo un poco de la evolución del marco de trabajo de desarrollo de Microsoft y la evolución de estos, nos enfocaremos en un tema que es de importancia en cuanto a la obsolescencia de los marcos de trabajo y específicamente .Net Core ya que su versión 2.2 se encuentra fuera de soporte por parte de Microsoft y el paso de Migración hacia su nueva versión, .Net Core 3.1 es una operación quirúrgica.
La Migración
La pregunta que nos debemos plantear al tomar la decisión para migrar de la versión .Net Core 2.2 hacia la versión .Net Core 3.1 debe basarse en la cantidad de librerías que tiene nuestro proyecto y de éstas cuáles se van a ver profundamente afectadas con la migración. Si está pensando en hacer esta migración, las siguientes librerías se van a ver afectadas y debe de tomarlo en cuenta:
- Obsolete Antiforgery, CORS, Diagnostics, MVC, and Routing APIs removed
- "Pubternal" APIs removed
- Authentication: Google+ deprecation
- Authentication: HttpContext.Authentication property removed
- Authentication: Newtonsoft.Json types replaced
- Authentication: OAuthHandler ExchangeCodeAsync signature changed
- Authorization: AddAuthorization overload moved to different assembly
- Authorization: IAllowAnonymous removed from AuthorizationFilterContext.Filters
- Authorization: IAuthorizationPolicyProvider implementations require new method
- Caching: CompactOnMemoryPressure property removed
- Caching: Microsoft.Extensions.Caching.SqlServer uses new SqlClient package
- Caching: ResponseCaching "pubternal" types changed to internal
- Data Protection: DataProtection.AzureStorage uses new Azure Storage APIs
- Hosting: AspNetCoreModule V1 removed from Windows Hosting Bundle
- Hosting: Generic host restricts Startup constructor injection
- Hosting: HTTPS redirection enabled for IIS out-of-process apps
- Hosting: IHostingEnvironment and IApplicationLifetime types replaced
- Hosting: ObjectPoolProvider removed from WebHostBuilder dependencies
- HTTP: Browser SameSite changes impact authentication
- HTTP: DefaultHttpContext extensibility removed
- HTTP: HeaderNames fields changed to static readonly
- HTTP: Response body infrastructure changes
- HTTP: Some cookie SameSite default values changed
- HTTP: Synchronous IO disabled by default
- Identity: AddDefaultUI method overload removed
- Identity: UI Bootstrap version change
- Identity: SignInAsync throws exception for unauthenticated identity
- Identity: SignInManager constructor accepts new parameter
- Identity: UI uses static web assets feature
- Kestrel: Connection adapters removed
- Kestrel: Empty HTTPS assembly removed
- Kestrel: Request trailer headers moved to new collection
- Kestrel: Transport abstraction layer changes
- Localization: APIs marked obsolete
- Logging: DebugLogger class made internal
- MVC: Controller action Async suffix removed
- MVC: JsonResult moved to Microsoft.AspNetCore.Mvc.Core
- MVC: Precompilation tool deprecated
- MVC: Types changed to internal
- MVC: Web API compatibility shim removed
- Razor: Runtime compilation moved to a package
- Session state: Obsolete APIs removed
- Shared framework: Assembly removal from Microsoft.AspNetCore.App
- Shared framework: Microsoft.AspNetCore.All removed
- SignalR: HandshakeProtocol.SuccessHandshakeData replaced
- SignalR: HubConnection methods removed
- SignalR: HubConnectionContext constructors changed
- SignalR: JavaScript client package name change
- SignalR: Obsolete APIs
- SPAs: SpaServices and NodeServices marked obsolete
- SPAs: SpaServices and NodeServices console logger fallback default change
- Target framework: .NET Framework not supporte
Además de tomar en cuenta la lista anterior, realizar dicha migración significa enfocar algunos esfuerzos en:
- Archivos de proyecto (.csproj): Verificar los errores de compilación y las advertencias que hacen referencia a la configuración del archivo del proyecto, ya que muchas de las entradas en el mismo son inútiles en .NET Core 3.1.
- Actualizaciones de Nugets: Indudablemente, el siguiente esfuerzo que se debe hacer es actualizar el resto de los paquetes utilizados por la aplicación a la versión más reciente posible.
- Archivo de Inicio (Startup.cs): Dado que en la versión 3.0 de Asp.Net Core, la configuración de la ruta cambió por completo, el Framework provee más opciones para situaciones específicas, por lo que se puede agregar la configuración solo para los controladores y la primer tarea en este punto es eliminar las referencias a Microsoft.AspNetCore.Mvc para usar Microsoft.Extensions.Hosting.
En resumen, realizar la migración de la versión es una tarea que se debe realizar con mucho detalle y posiblemente requiera de tiempo para realizar los ajustes y estabilizar el aplicativo, sin embargo; la ganancia de realizar dicho esfuerzo es tener una aplicación que tiene un marco de trabajo con respaldo de soporte por parte del proveedor y que además es bastante estable, que, aunque contiene muchos cambios de ruptura, agrega más herramientas que pueden ser usadas por los desarrolladores.
Luis Alfonso Rojas Calderón | Development Leader | Máster en Computación e Informática