Compartir vía

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 actualizació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 actualizar 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 actualizar 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, consulte Uso del paquete de compatibilidad de Windows para migrar el 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, consulte Analizar sus dependencias para portar 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 Analice sus dependencias para portar código desde .NET Framework a.

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 monikers de destino, 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 otros dominios de aplicación. 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 objetos delegados lanzan PlatformNotSupportedException.

  • Seguridad de acceso al código (CAS)

    CAS era una técnica de sandboxing soportada por .NET Framework, pero quedó 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 es compatible con .NET. Para obtener 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:

  • Libraries
  • 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 actualizació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 modernización de aplicaciones de Copilot de GitHub

Modernización de aplicaciones con GitHub Copilot es un asistente de chat de GitHub Copilot que le ayuda a planificar y actualizar proyectos a versiones más recientes de .NET, migrar a Azure, actualizar dependencias y aplicar correcciones de código. La migración de Azure se basa en la evaluación de aplicaciones y código para .NET

Este asistente de chat admite las siguientes rutas de actualización:

  • Actualice proyectos de versiones anteriores de .NET a la versión más reciente.
  • Actualice proyectos de .NET Framework a la versión más reciente de .NET.
  • Modernice el código base con nuevas características.
  • Migre componentes y servicios a Azure.

También funciona en varios tipos de proyecto, como:

  • ASP.NET y tecnologías relacionadas, como MVC, Razor Pages, Web API
  • Blazor
  • Funciones de Azure
  • Windows Presentation Foundation
  • Windows Forms
  • Bibliotecas de clases
  • Aplicaciones de consola

Cuándo usar:

Utilice la modernización de aplicaciones Copilot de GitHub cuando desee una experiencia de un extremo a otro con tecnología de inteligencia artificial para actualizar proyectos y dependencias de .NET Framework a las versiones modernas de .NET, que abarcan la evaluación, la planificación, la remediación y las instrucciones para migrar aplicaciones a Azure.

Evaluación de aplicaciones y código para .NET

La evaluación de código y aplicaciones de Azure Migrate para .NET proporciona código y análisis de aplicaciones, junto con recomendaciones para planear implementaciones en la nube. Le ayuda a ejecutar con confianza soluciones críticas para la empresa en la nube ofreciendo una evaluación centrada en el desarrollador del código fuente. La herramienta también proporciona recomendaciones y ejemplos para optimizar el código y las configuraciones de Azure, siguiendo los procedimientos recomendados del sector.

Esta herramienta también es utilizada por el servicio de modernización de aplicaciones de GitHub Copilot para mejorar la experiencia de .NET.

Cuándo usar:

Usa la aplicación Azure Migrate junto con el conjunto de herramientas de evaluación de código para .NET para evaluar y obtener recomendaciones sobre cómo migrar una base de código existente a Azure. La evaluación de código y aplicación de Azure Migrate es básicamente un subconjunto de la modernización de aplicaciones de GitHub Copilot para la experiencia de .NET.

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 actualización. La herramienta incluye la instalación de analizadores que pueden ayudar a completar la actualización. Esta herramienta funciona en los siguientes tipos de aplicaciones de .NET Framework:

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

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

Cuándo usar:

Se usa cuando una solución con tecnología de inteligencia artificial como la modernización de aplicaciones de GitHub Copilot no está disponible.

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 la plataforma analiza si usa o no una API que produce un PlatformNotSupportedException en tiempo de ejecución. Aunque es poco probable encontrar una de estas APIs si está migrando desde .NET Framework 4.7.2 o superior, es bueno 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:

✔️ CONSIDERA usar la app de modernización de GitHub Copilot para actualizar tus proyectos. GitHub Copilot es eficaz para identificar y corregir incompatibilidades al migrar. Automatiza la mayoría de los pasos manuales que se detallan en este artículo y le ofrece un excelente punto de partida para continuar con la ruta de actualización.

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

✔️ Actualice de un archivo packages.config de NuGet a configuraciones dentro del 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.

✔️ Reorienta tu 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).

✔️ Especifique .NET 8+ para proyectos de Windows Forms y WPF. .NET 8 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 actualizar una biblioteca que también se puede usar con proyectos de .NET Framework. También puede establecer varios destinos para su biblioteca, apuntando tanto a .NET Framework como a .NET Standard.

✔️ Agregue referencia al paquete NuGet Microsoft.Windows.Compatibility si, después de migrar, obtendrá errores de las API que faltan. Hay disponible una gran parte de la superficie de la API de .NET Framework a través del paquete NuGet.

Consulte también

  • Last updated on