Hoy vamos a ver la estrategia de migración que he adoptado para migrar una aplicación desarrollada en NET Framwork 4.7.2 a NET CORE 3.1 Existe mucha documentación en la red, como punto de partida me he basado en estas recomendaciones: https://docs.microsoft.com/en-us/dotnet/architecture/porting-existing-aspnet-apps/strategies-migrating-in-production

En mi caso concreto la aplicación a migrar es muy grande, con mas de 200 proyectos, y se encuentra en continuo cambio, por lo que no es posible parar toda la maquinaria para hacer la migración sin interferencias. Partiendo de esta premisa hemos marcado una serie de hitos consecutivos:

  1. Refactor del código actual.

En esta fase vamos a realizar cambios en nuestros proyectos para facilitar la futura actualización. El más importante es la actualización de paquetes nuget a versiones que soporten Net Standard 2.0. De todos estos hay uno al que habra que prestar especial atención, WindowsAzure.Storage. Esta libreria está deprecada hasta la versión v12, y en esta versión cambia la api, por lo que hay que recodificar el código. Otra opción es cambiar a la versión v11 que mantiene la api de las versiones anteriores y solo es necesario cambiar namespaces y algún cambio menor, pero he encontrado serios problemas de rendimiento en las llamadas sincronas. La siguiente libreria sobre la que tendremos que tomar decisiones es EntityFramework. En nuestro caso no tenemos intención de migrar a EF Core y mantendremos esta libreria. El primer inconveniente que encontramos es que no implementa Net Standard 2.0 sino que es Net Standard 2.1. Esto va a implicar compilar los proyectos que usen esta libreria en dos plataformas, net472 y netcoreapp3.1. Con el nuevo formato de proyecto podemos compilar facilmente en varias plataformas destino <TargetFrameworks>net472;netcoreapp3.1</TargetFrameworks> Lo ideal para mantener el máximo codigo posible en proyectos Net Standard 2.0 es que se separe a otro proyecto todo el código que dependa de MVC y EF, este es otro de los pasos del refactor previo.

  1.    Actualización de archivos de proyectos.

El siguiente paso es actualizar los proyectos (csproj) al nuevo formato SDK. Dependiendo del número de proyectos que tenga vuestra solución esto puede ser bastante pesado si se realiza de forma manual. Como comentaba anteriormente, en este caso son mas de 200, hay que automatizar el cambio. Microsoft sale al rescate, existe una herramienta que contiene un wizard desde el que podemos ir migrando los proyectos. https://devblogs.microsoft.com/dotnet/introducing-the-net-upgrade-assistant-preview/ https://docs.microsoft.com/es-es/dotnet/core/porting/upgrade-assistant-aspnetmvc
Cuando selecionamos la solución, nos pide que establezcamos cual es el proyecto de inicio, y desde ese nos indica el orden recomendado de proyectos en el que hay que hacer la migración. Podemos copiar el orden para posteriormente montar un pequeño script e ir ejecutando cada uno de los proyectos de manera individual. La herramienta tiene la opción --non-interactive para el procesamiento automatico, pero esto realizaria la migración completa a NET CORE, y nosotros solo queremos actualizar los proyectos, cambiar a PackageReference y realizar la limpia de paquetes nuget, packageReference funciona en modo transitivo, paquetes de proyectos dependientes son accesibles desde nuestro proyecto si no indicamos lo contrario. Por suerte podemos hacer una pequeña modificación al código fuente para saltarnos los pasos que no nos interesan. https://github.com/dotnet/upgrade-assistant
A modo de ejemplo os dejo cual ha sido mi cambio:
data/admin/2021/4/uppgrade_assistant_change.PNG Ya podemos compilar la herramienta con nuestro cambio y montar un script al estilo:

C:\upgrade_assistant\Microsoft.DotNet.UpgradeAssistant.Cli.exe --skip-backup --non-interactive "project1.csproj"
...
...
C:\upgrade_assistant\Microsoft.DotNet.UpgradeAssistant.Cli.exe --skip-backup --non-interactive "projectN.csproj"

Los proyectos MVC los va a migrar como aplicaciones de consola, tendremos que cambiarlos a librerias de clases. Os dejo un enlace para que veais como se pueden depurar y arrancarlos desde IIS Express. https://stackoverflow.com/questions/47915353/can-the-new-csproj-file-structure-be-used-with-a-asp-net-framework-project

  1.  Migración de los proyectos de tipo libreria de clases.

Es hora de empezar a compilar las librerias en NetStandard, la recomendación es seguir el mismo orden que tenemos del paso anterior, comenzando por los proyectos que no tienen dependencias con otros e ir subiendo. Para tener una visión de como es nuestro código de compatible con NetStandard o Net Core, vamos a ejecutar el analisis de código que nos proporciona otra herramienta https://docs.microsoft.com/es-es/dotnet/standard/analyzers/portability-analyzer Podemos analizar los resultados y tener una visión de los cambios de código que tendremos que realizar. Para las librerías de clases que tienen dependencias con MVC, EF, etc. es necesario adaptar el código y archivo de proyecto para compilar en dos versiones, Net Framework 4.7.2 y Net Core 3.1 La finalidad es mantener código original que se compila en Net Framework 4.7.2 sin cambios. Usando directivas condicionales en el código fuente (#IF Net472)

  1.  Migración de los proyectos de presentacion (MVC, Consolas, etc..)

Si hemos tenido éxito en las fases anteriores estaremos ejectando nuestras aplicaciones en net472 con todas las referencias a proyectos compilados en netstandard2.0 o net472/netcoreapp3.1. Migrar un proyecto MVC es mucho más complicado que migrar librerias de clases, aqui veo dos opciones:

  1. Modificar sobre el proyecto actual.
    Si optamos por esta opción, la herramienta que usamos para actualizar los archivos de proyectos, .NET upgrade-assistant, puede ayudarnos bastante.
  2. Crear un nuevo proyecto e ir copiando.

Happy Coding!