Compartir a través de

Información general sobre la migración de .NET Framework a .NET

En este artículo se proporciona información general sobre lo que debe tener en cuenta al migrar el código de .NET Framework a .NET (anteriormente denominado .NET Core). La migración a .NET desde .NET Framework es relativamente sencilla para muchos proyectos. La complejidad de los proyectos determina cuánto trabajo tendrá que hacer después de la migración inicial de los archivos del proyecto.

Los proyectos en los que el modelo de aplicación está disponible en .NET, como bibliotecas, aplicaciones de consola y aplicaciones de escritorio, normalmente requieren poco cambio. Los proyectos que requieren un nuevo modelo de aplicación, como pasar a ASP.NET Core desde ASP.NET, requieren más trabajo. Muchos patrones del modelo de aplicación antiguo tienen equivalentes que se pueden usar durante la conversión.

Tecnologías de escritorio de Windows

Muchas aplicaciones creadas para .NET Framework usan una tecnología de escritorio como Windows Forms o Windows Presentation Foundation (WPF). Tanto Windows Forms como WPF están disponibles en .NET, pero siguen siendo tecnologías solo de Windows.

Tenga en cuenta las siguientes dependencias antes de migrar una aplicación de Windows Forms o WPF:

  • Los archivos de proyecto para .NET usan un formato diferente al de .NET Framework.
  • El proyecto puede usar una API que no está disponible en .NET.
  • Es posible que los controles y bibliotecas de terceros no se hayan migrado a .NET y solo estén disponibles para .NET Framework.
  • El proyecto usa una tecnología que ya no está disponible en .NET.

.NET usa las versiones de código abierto de Windows Forms y WPF e incluye mejoras en .NET Framework.

Para ver tutoriales sobre cómo migrar la aplicación de escritorio a .NET, consulte uno de los siguientes artículos:

API específicas de Windows

Las aplicaciones todavía pueden usar bibliotecas nativas de P/Invoke en plataformas compatibles con .NET. Esta tecnología no se limita a Windows. Sin embargo, si la biblioteca a la que hace referencia es específica de Windows, como una user32.dll o kernel32.dll, el código solo funciona en Windows. Para cada plataforma en la que quieras que se ejecute la aplicación, tienes que buscar versiones específicas de la plataforma o hacer que el código sea lo suficientemente genérico como para ejecutarse en todas las plataformas.

Al migrar una aplicación de .NET Framework a .NET, es probable que la aplicación use una biblioteca proporcionada por .NET Framework. Muchas API que estaban disponibles en .NET Framework no se migraron a .NET porque se basaban en la tecnología específica de Windows, como el Registro de Windows o el modelo de dibujo de GDI+.

El paquete de compatibilidad de Windows proporciona una gran parte de la superficie de la API de .NET Framework a .NET y se proporciona a través del paquete NuGet Microsoft.Windows.Compatibility.

Para obtener más información, vea Usar el paquete de compatibilidad de Windows para migrar código a .NET.

Modo de compatibilidad de .NET Framework

El modo de compatibilidad de .NET Framework se introdujo en .NET Standard 2.0. El modo de compatibilidad permite que los proyectos de .NET Standard y .NET hagan referencia a bibliotecas de .NET Framework como si se compilaran para la plataforma de destino del proyecto. Sin embargo, algunas implementaciones de .NET podrían admitir un fragmento mayor de .NET Framework que otras. Por ejemplo, .NET Core 3.0 amplía el modo de compatibilidad de .NET Framework a Windows Forms y WPF. Hacer referencia a bibliotecas de .NET Framework no funciona para todos los proyectos, como si la biblioteca usa API de WPF, pero desbloquea muchos escenarios de portabilidad. Para obtener más información, vea Analyze your dependencies to port code from .NET Framework to .NET (Análisis de sus dependencias para migrar código de .NET Framework a .NET).

Hacer referencia a bibliotecas de .NET Framework no funciona en todos los casos, ya que depende de las API de .NET Framework que se usaron y de si estas API son compatibles o no con el marco de destino del proyecto. Además, algunas de las API de .NET Framework solo funcionarán en Windows. El modo de compatibilidad de .NET Framework desbloquea muchos escenarios de portabilidad, pero debe probar los proyectos para asegurarse de que también funcionan en tiempo de ejecución. Para más información, consulte Analizar las dependencias para portar código del .NET Framework a .NET Core.

Cambios de marco de destino en proyectos de estilo SDK

Como se mencionó anteriormente, los archivos de proyecto para .NET usan un formato diferente al de .NET Framework, conocido como formato de proyecto de estilo SDK. Incluso si no va a pasar de .NET Framework a .NET, debe actualizar el archivo de proyecto al formato más reciente. La manera de especificar un marco de destino es diferente en los proyectos de estilo SDK. En .NET Framework, la <TargetFrameworkVersion> propiedad se usa con un moniker que especifica la versión de .NET Framework. Por ejemplo, .NET Framework 4.7.2 tiene el siguiente aspecto:

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

Un proyecto de estilo SDK usa una propiedad diferente para identificar la plataforma de destino, la <TargetFramework> propiedad . Cuando el destino es .NET Framework, el moniker comienza con net y termina con la versión de .NET Framework sin períodos. Por ejemplo, el moniker para tener como destino .NET Framework 4.7.2 es net472:

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

Para obtener una lista de todos los identificadores de objetivo, consulte Plataformas de destino en proyectos de estilo SDK.

Tecnologías no disponibles

Hay algunas tecnologías en .NET Framework que no existen en .NET:

  • Dominios de aplicación

    No se admite la creación de dominios de aplicación adicionales. Para el aislamiento de código, use procesos o contenedores independientes como alternativa.

  • Comunicación remota

    La comunicación remota se usa para comunicarse entre dominios de aplicación, que ya no se admiten. Para una comunicación sencilla entre procesos, considere los mecanismos de comunicación entre procesos (IPC) como alternativa a la comunicación remota, como la clase System.IO.Pipes o la clase MemoryMappedFile. Para escenarios más complejos, considere marcos como StreamJsonRpc o ASP.NET Core (ya sea mediante gRPC o servicios de API web RESTful).

    Dado que no se admite la comunicación remota, las llamadas a BeginInvoke() y EndInvoke() en los objetos delegados producirán PlatformNotSupportedException.

  • Seguridad de acceso al código (CAS)

    CAS era una técnica de sandboxing compatible con .NET Framework, pero obsoleta en .NET Framework 4.0. Se reemplazó por transparencia de seguridad y no se admite en .NET. En su lugar, use los límites de seguridad proporcionados por el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario.

  • Transparencia de seguridad

    De forma similar a CAS, la técnica de sandboxing de transparencia de seguridad ya no se recomienda para las aplicaciones de .NET Framework y no se admite en .NET. En su lugar, use los límites de seguridad proporcionados por el sistema operativo, como la virtualización, los contenedores o las cuentas de usuario.

  • System.EnterpriseServices

    System.EnterpriseServices (COM+) no se admite en .NET.

  • Windows Workflow Foundation (WF)

    WF no se admite en .NET. Para encontrar una alternativa, consulte CoreWF.

Para obtener más información sobre estas tecnologías no admitidas, consulte Tecnologías de .NET Framework no disponibles en .NET 6+.

Multiplataforma

.NET (anteriormente conocido como .NET Core) está diseñado para ser multiplataforma. Si el código no depende de tecnologías específicas de Windows, puede ejecutarse en otras plataformas como macOS, Linux y Android. Este código incluye tipos de proyecto como:

  • Bibliotecas
  • Herramientas basadas en consola
  • Automatización
  • sitios de ASP.NET

.NET Framework es un componente solo de Windows. Cuando el código usa tecnologías o API específicas de Windows, como Windows Forms y WPF, el código todavía se puede ejecutar en .NET, pero no se ejecuta en otros sistemas operativos.

Es posible que la biblioteca o la aplicación basada en consola se puedan usar multiplataforma sin cambiar mucho. Al migrar a .NET, es posible que quiera tener esto en cuenta y probar la aplicación en otras plataformas.

El futuro de .NET Standard

.NET Standard es una especificación formal de las API de .NET que están disponibles en varias implementaciones de .NET. La motivación de .NET Standard era establecer una mayor uniformidad en el ecosistema de .NET. A partir de .NET 5, se ha adoptado un enfoque diferente para establecer la uniformidad y este nuevo enfoque elimina la necesidad de .NET Standard en muchos escenarios. Para más información, consulte .NET 5+ y .NET Standard.

.NET Standard 2.0 era la última versión para admitir .NET Framework.

Herramientas para ayudar a migrar

En lugar de migrar manualmente una aplicación de .NET Framework a .NET, puede usar diferentes herramientas para ayudar a automatizar algunos aspectos de la migración. La migración de un proyecto complejo es, en sí mismo, un proceso complejo. Las herramientas pueden ayudar en ese recorrido.

Incluso si usa una herramienta para ayudar a portar la aplicación, debe revisar la sección Consideraciones al migrar de este artículo.

Asistente para actualización de .NET

El Asistente para actualización de .NET es una herramienta de línea de comandos que se puede ejecutar en diferentes tipos de aplicaciones de .NET Framework. Está diseñado para ayudar a actualizar aplicaciones de .NET Framework a .NET. Después de ejecutar la herramienta, en la mayoría de los casos, la aplicación requerirá más esfuerzo para completar la migración. La herramienta incluye la instalación de analizadores que pueden ayudar a completar la migración. Esta herramienta funciona en los siguientes tipos de aplicaciones de .NET Framework:

  • Windows Forms
  • WPF (Windows Presentation Foundation)
  • ASP.NET MVC
  • Consola
  • Bibliotecas de clases

Esta herramienta usa las otras herramientas enumeradas en este artículo, como try-convert y guía el proceso de migración. Para obtener más información sobre la herramienta, vea Información general del Asistente para actualización de .NET.

try-convert

La try-convert herramienta es una herramienta global de .NET que puede convertir un proyecto o una solución completa en el SDK de .NET, incluida la migración de aplicaciones de escritorio a .NET. Sin embargo, esta herramienta no se recomienda si el proyecto tiene un proceso de compilación complicado, como tareas personalizadas, destinos o importaciones.

Para obtener más información, consulte el repositorio de try-convert GitHub.

Analizador de compatibilidad de plataformas

El analizador de compatibilidad de plataforma analiza si usa o no una API que produce una PlatformNotSupportedException excepción en tiempo de ejecución. Aunque es poco probable que encuentre una de estas API si está pasando de .NET Framework 4.7.2 o superior, es conveniente comprobarlo. Para obtener más información sobre las API que producen excepciones en .NET, consulte API que siempre inician excepciones en .NET Core.

Para obtener más información, consulte Analizador de compatibilidad de plataformas.

Consideraciones al migrar

Al migrar la aplicación a .NET, tenga en cuenta las siguientes sugerencias en orden:

✔️ CONSIDERE la posibilidad de usar el Asistente para actualización de .NET para migrar los proyectos. Aunque esta herramienta está en versión preliminar, automatiza la mayoría de los pasos manuales que se detallan en este artículo y proporciona un excelente punto de partida para continuar con la ruta de migración.

✔️ Considere la posibilidad de examinar primero las dependencias. Las dependencias deben tener como destino .NET, .NET Standard o .NET Core.

✔️ Realice la migración desde un archivo NuGet packages.config a la configuración en PackageReference el archivo del proyecto. Utiliza Visual Studio para convertir el package.config archivo.

✔️ CONSIDERE la posibilidad de actualizar al formato de archivo de proyecto más reciente aunque aún no pueda migrar la aplicación. Los proyectos de .NET Framework usan un formato de proyecto obsoleto. Aunque el formato de proyecto más reciente, conocido como proyectos de estilo SDK, se creó para .NET Core y versiones posteriores, el formato también funciona con .NET Framework. Tener el archivo del proyecto en el formato más reciente te da una buena base para migrar la aplicación en el futuro.

✔️ Asegúrese de volver a dirigir su proyecto de .NET Framework a al menos .NET Framework 4.7.2. Esto garantiza la disponibilidad de las alternativas de API más recientes para los casos en los que .NET Standard no admite las API existentes.

✔️ CONSIDERE la posibilidad de tener como destino .NET 8, que es una versión de soporte técnico a largo plazo (LTS).

✔️ HAGA como destino .NET 6+ para proyectos de Windows Forms y WPF . .NET 6 y versiones posteriores contienen muchas mejoras para las aplicaciones de escritorio.

✔️ CONSIDERE la posibilidad de tener como destino .NET Standard 2.0 si va a migrar una biblioteca que también se puede usar con proyectos de .NET Framework. También puede dirigir su biblioteca a múltiples plataformas, apuntando tanto al .NET Framework como al .NET Standard.

✔️ Agregue referencia al paquete NuGet Microsoft.Windows.Compatibility si, después de migrar, obtengas errores de APIs faltantes. Una gran parte de la superficie de la API de .NET Framework está disponible para .NET a través del paquete NuGet.

Consulte también