Compartir a través de

Creación de un plan de portabilidad

Se recomienda usar el Asistente para actualización de .NET de Visual Studio para actualizar el código de .NET Framework a las versiones más recientes de .NET. Para obtener más información, consulte la entrada de blog Actualización de los proyectos de .NET con Visual Studio.

Importante

El puerto de API ha quedado en desuso en favor del análisis binario con la herramienta Asistente para actualización de .NET. El servicio back-end del puerto API se cerró, por lo que para usar la herramienta, es necesario hacerlo sin conexión. Para más información, vea Archivo Léame de API Port de .NET.

Antes de ir directamente al código, tómese el tiempo necesario para seguir los pasos recomendados previos a la migración. En este artículo se proporciona información sobre los tipos de problemas que puede encontrar y se le ayuda a decidir sobre el enfoque que tenga más sentido.

Portabilidad del código

Asegúrese de seguir los requisitos previos para portar código antes de continuar. Prepárese para decidir cuál es el mejor enfoque en su caso y comience a portar código.

Trabajar primero con el compilador

Este enfoque funciona bien con proyectos pequeños o proyectos que no usan muchas API de .NET Framework. El enfoque es sencillo:

  1. De manera opcional, ejecute ApiPort en el proyecto. Si ejecuta ApiPort, consulte el informe para obtener información sobre los problemas que debe solucionar.
  2. Copie todo el código a un nuevo proyecto de .NET.
  3. Mientras consulta el informe de portabilidad (en caso de que se haya generado), solucione los errores del compilador hasta que el proyecto esté totalmente compilado.

Aunque no está estructurado, este enfoque centrado en el código suele resolver los problemas rápidamente. Un proyecto que solo contiene modelos de datos puede ser un candidato ideal para este enfoque.

Permanecer en .NET Framework hasta solucionar los problemas de portabilidad

Este puede ser el mejor enfoque si prefiere que el código se compile durante todo el proceso. El enfoque es el siguiente:

  1. Ejecute ApiPort en un proyecto.
  2. Use distintas API portátiles para solucionar los problemas.
  3. Anote todas las áreas en las que no se permite usar una alternativa directa.
  4. Repita los pasos anteriores para todos los proyectos que quiera trasladar hasta tener la seguridad de que están listos para copiarlos en un proyecto nuevo de .NET.
  5. Copie el código en un nuevo proyecto de .NET.
  6. Solucione todos los problemas en los que se indica que no existe una alternativa directa.

Este enfoque prudente es más estructurado que simplemente solucionar los errores del compilador, pero de todos modos está relativamente centrado en el código y tiene la ventaja de que siempre hay código que se puede compilar. La manera en que puede solucionar ciertos problemas que no se podrían solucionar si solo se usa otra API varía considerablemente. Es posible que deba desarrollar un plan más integral para ciertos proyectos, un aspecto que se abarca en el enfoque siguiente.

Desarrollar un plan integral de ataque

Este puede ser el mejor enfoque para proyectos de mayor tamaño y más complejos, en los que puede ser necesario volver a estructurar el código o reescribir ciertas áreas de código para admitir .NET. El enfoque es el siguiente:

  1. Ejecute ApiPort en un proyecto.

  2. Observe dónde se usa cada tipo no portátil y cómo ese uso afecta a la portabilidad general.

    • Comprenda la naturaleza de esos tipos. ¿Son pocos, pero se usan con frecuencia? ¿Son muchos, pero no se usan con frecuencia? ¿Se usan de manera concentrada o se distribuyen en todo el código?
    • ¿Es simple aislar código no portátil para poder trabajar con él con más eficacia?
    • ¿Es necesario refactorizar el código?
    • En el caso de los tipos no portátiles, ¿existen API alternativas que permitan realizar la misma tarea? Por ejemplo, si va a usar la clase WebClient, utilice la clase HttpClient en su lugar.
    • ¿Hay API portátiles distintas disponibles para realizar una tarea, incluso si no se trata de un reemplazo? Por ejemplo, si usa XmlSchema para analizar XML, pero no necesita la detección de esquemas XML, puede usar las API System.Xml.Linq e implementar el análisis por su cuenta en lugar de depender de una API.

  3. Si tiene ensamblados difíciles de trasladar, ¿debe pensarse en dejarlos en .NET Framework por ahora? Algunos aspectos que debe considerar:

    • Es posible que en la biblioteca tenga alguna funcionalidad no compatible con .NET, porque depende demasiado de la funcionalidad específica de Windows o de .NET Framework. ¿Debe considerarse la posibilidad de dejar atrás esa funcionalidad por ahora y lanzar una versión temporal para .NET de la biblioteca con menos características hasta que haya recursos disponibles para portar las características?
    • ¿Sería útil una refactorización en este caso?

  4. ¿Es razonable escribir su propia implementación de una API de .NET Framework no disponible?

    Podría considerar copiar, modificar y usar código del código fuente de referencia de .NET Framework. El código fuente de referencia está sujeto a la licencia de MIT, por lo que tiene plena libertad para usar la fuente como base para su propio código. Solo debe asegurarse de atribuir adecuadamente la propiedad de Microsoft en el código.

  5. Repita este proceso las veces que sea necesario para proyectos distintos.

La fase de análisis puede tardar un poco en función del tamaño de la base de código. Dedicar tiempo en esta fase a comprender profundamente el ámbito de los cambios que se necesitan y a desarrollar un plan suele ahorrar tiempo a largo plazo, principalmente si tiene una base de código compleja.

El plan podría significar realizar cambios importantes en la base de código mientras .NET Framework 4.7.2 sigue seleccionado como destino. Se trata de una versión más estructurada del enfoque anterior. La forma de ejecutar el plan depende de la base de código.

Enfoque mixto

Es probable que vaya a combinar los enfoques anteriores en función de cada proyecto. Debe hacer lo que tenga más sentido para la base de código.

Portar las pruebas

La mejor forma de asegurarse de que todo funciona correctamente cuando se ha trasladado el código consiste en probarlo mientras se traslada a .NET. Para ello, tendrá que usar un marco de pruebas que compile y ejecute pruebas para .NET. Actualmente tiene 3 opciones:

En última instancia, el esfuerzo de portabilidad depende significativamente de la estructura del código .NET Framework. Una forma conveniente de portar el código consiste en comenzar por la base de la biblioteca, que son los componentes fundamentales del código. Pueden ser los modelos de datos u otras clases y métodos fundamentales que todo lo demás usa directa o indirectamente.

  1. Porte el proyecto de prueba que comprueba el nivel de la biblioteca cuya portabilidad se está realizando actualmente.
  2. Copie la base de la biblioteca en un proyecto de .NET nuevo y seleccione la versión de .NET Standard que quiere admitir.
  3. Haga los cambios necesarios para la compilación del código. Muchas de estas acciones pueden requerir agregar dependencias del paquete NuGet al archivo csproj.
  4. Ejecute las pruebas y haga los ajustes que sean necesarios.
  5. Elija el nivel de código siguiente que se va a portar y repita los pasos anteriores.

Si empieza por la base de la biblioteca y avanza a partir de ella para probar cada nivel según sea necesario, la portabilidad es un proceso sistemático en el que se aíslan los problemas a un nivel de código a la vez.

Pasos siguientes