En septiembre, lanzamos la compatibilidad con .NET Core para crear aplicaciones de escritorio de Windows, incluidos WPF y Windows Forms. Desde entonces, nos complace ver que muchos desarrolladores comparten sus historias sobre la transferencia de aplicaciones de escritorio a .NET Core. Constantemente escuchamos historias de desarrolladores .NET de aplicaciones de escritorio de Windows sobre cómo apoyan su negocio con WPF y Windows Forms, especialmente cuando el escritorio gana, incluyendo:
- Aplicaciones FOD (formularios sobre datos) con una interfaz de usuario densa
- Interfaz de usuario receptiva y de baja latencia
- Aplicaciones que deben funcionar sin conexión
- Aplicaciones con dependencias en controladores de dispositivos personalizados
Eche un vistazo para obtener más información sobre los beneficios de .NET Core para crear aplicaciones de Windows.
¿Por qué el escritorio de Windows en .NET Core?
.NET Core (y en el futuro .NET 5, construido sobre la base de .NET Core) se convertirá en el futuro de .NET. Nos esforzamos por admitir .NET Framework el mayor tiempo posible, sin embargo, no recibirá ninguna característica nueva, solo se agregará a .NET Core (y, en última instancia, .NET 5). Para mejorar las pilas de escritorio de Windows y permitir que los desarrolladores de escritorio .NET se beneficien de todas las actualizaciones futuras, presentamos Windows Forms y WPF para .NET Core. Seguirán siendo tecnologías exclusivas de Windows, ya que están estrechamente relacionadas con las API de Windows. Pero .NET Core, además de multiplataforma, tiene muchas otras características que pueden mejorar las aplicaciones de escritorio.
En primer lugar, todas las mejoras de tiempo de ejecución y las características del lenguaje se agregarán solo en .NET Core y, en el futuro, en .NET 5. Un buen ejemplo aquí es C # 8, que estuvo disponible en .NET Core 3.0. Además, las versiones de .NET Core de Windows Forms y WPF se convertirán en parte de la plataforma .NET 5. Y, al portar su aplicación a .NET Core, la preparará para .NET 5.
Además, .NET Core proporciona flexibilidad de implementación para sus aplicaciones con nuevas opciones no disponibles en .NET Framework, como:
- Despliegue paralelo Ahora puede tener varias versiones de .NET Core en una computadora y puede elegir en qué versión se centrará cada una de sus aplicaciones.
- Despliegue fuera de línea. Puede implementar la plataforma .NET Core con sus aplicaciones y volverse completamente independiente del entorno del usuario final: su aplicación tiene todo lo que necesita para ejecutarse en cualquier computadora con Windows.
- Tamaños de aplicación más pequeños. En .NET Core 3, introdujimos una nueva característica llamada enlazador (también llamado a veces recortador) que analizará su código e incluirá en una implementación fuera de línea solo aquellos ensamblados de .NET Core que sean necesarios para su aplicación. Por lo tanto, todos los detalles de la plataforma que no se utilizan en su caso se eliminarán.
- Archivos individuales .exe. Puede empaquetar su aplicación y plataforma .NET Core en un solo archivo .exe.
- Rendimiento mejorado en tiempo de ejecución. .NET Core tiene muchas optimizaciones de rendimiento sobre .NET Framework. Si recuerda el historial de .NET Core, que fue creado originalmente para las cargas de trabajo en la web y el servidor, ayuda a comprender si su aplicación puede experimentar beneficios notables al optimizar el tiempo de ejecución. En particular, es probable que las aplicaciones de escritorio que dependen en gran medida de las operaciones de E / S de archivos, redes y bases de datos muestren mejoras de rendimiento para estos escenarios. Algunas áreas en las que puede no notar cambios significativos se relacionan con el rendimiento de la interfaz de usuario o el inicio de la aplicación.
Al configurar las propiedades
<PublishSingleFile> ,
<RuntimeIdentifier> y
<PublishTrimmed> en el perfil de publicación, puede implementar la aplicación independiente recortada como un único archivo .exe, como se muestra en el siguiente ejemplo.
<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup>
Diferencias entre el escritorio de .NET Framework y el escritorio de .NET Core
Al desarrollar aplicaciones de escritorio, no notará una gran diferencia entre las versiones de WPF y Windows Forms para .NET Framework y .NET Core. Parte de nuestros esfuerzos ha sido proporcionar similitudes funcionales entre estas plataformas de escritorio y mejorar el futuro de .NET Core.
Las aplicaciones WPF son totalmente compatibles con .NET Core, y puede comenzar a trabajar con ellas mientras trabajamos en actualizaciones y mejoras menores. Para Windows Forms, el tiempo de ejecución se ha portado completamente a .NET Core, y el equipo está trabajando actualmente en el Diseñador de Windows Forms. Planeamos prepararlo para el cuarto trimestre de 2020, pero por ahora puede consultar la versión preliminar del diseñador en
Visual Studio 16.4 Preview 3 o posterior. Recuerde marcar la casilla en Herramientas-> Opciones-> Características de vista previa-> Usar la vista previa del diseñador de formularios Windows Forms para aplicaciones .NET Core y reinicie Visual Studio. Tenga en cuenta que la experiencia con el uso sigue siendo limitada, ya que el trabajo todavía está en marcha.
Cambios importantes
Hubo algunos
cambios importantes en .NET Framework y .NET Core, pero la mayor parte del código relacionado con las formas de Windows Forms y WPF se transfirió a Core de la misma manera. Si anteriormente utilizó componentes como WCF Client, Code Access Security, App Domains, Interop y Remoting, deberá refactorizar el código si desea cambiar a .NET Core.
Una cosa a tener en cuenta: las rutas de salida predeterminadas en .NET Core son diferentes de las rutas en .NET Framework, por lo que si su código tiene algunas suposiciones sobre la estructura de archivos / carpetas de la aplicación en ejecución, entonces probablemente caerá en tiempo de ejecución.
También hay cambios en la configuración de las funciones .NET. En lugar de usar el archivo
machine.config , .NET Core usa el archivo
<something>.runtimeconfig.json que viene con la aplicación y tiene el mismo propósito principal e información similar. Algunas configuraciones, como
system.diagnostics ,
system.net o
system.net , no son compatibles, por lo que el archivo de configuración de la aplicación no se puede cargar si contiene alguna de estas secciones. Este cambio se aplica al rastreo
System.Diagnostics y a los scripts de cliente WCF que antes se configuraban normalmente con la configuración XML. En .NET Core, debes configurarlos en código. Para cambiar el comportamiento sin volver a compilar, considere personalizar los tipos de rastreo y WCF utilizando valores descargados de una fuente
Microsoft.Extensions.Configuration o de
appSettings .
Puede encontrar más información sobre las diferencias entre .NET Core y .NET Framework en la
documentación .
Para empezar
Mira estos breves tutoriales:
Portado de .NET Framework a .NET Core
En primer lugar, inicie el
Analizador de portabilidad (analizador de portabilidad) y, si es necesario, actualice el código para garantizar una compatibilidad del 100% con .NET Core. Aquí hay
instrucciones para usar el analizador de portabilidad. . Le recomendamos que utilice el control de origen o haga una copia de seguridad de su código antes de realizar cualquier cambio en su aplicación, en caso de que la refactorización falle de la manera deseada, y decida volver a su estado original.
Cuando su aplicación sea totalmente compatible con .NET Core, estará listo para portarla. Como punto de partida, puede probar la herramienta que creamos para ayudar a automatizar la conversión de sus proyectos de .NET Framework a .NET Core:
try-convert .
Es importante recordar que esta herramienta es solo un punto de partida en su viaje a .NET Core. Además, este no es un producto de Microsoft compatible. Aunque puede ayudarlo con algunos de los aspectos mecánicos de la migración, no manejará todos los escenarios o tipos de proyectos. Si hay proyectos en su solución que la herramienta rechaza o no puede convertir, deberá transferirlos manualmente. No se preocupe, hemos preparado muchas lecciones sobre cómo hacer esto (al final del artículo).
La herramienta try-convert intentará transferir los archivos de proyecto de estilo antiguo al nuevo estilo SDK y reconfigurar los proyectos correspondientes en .NET Core. Para sus bibliotecas, dejamos que usted elija la plataforma: .NET Core o .NET Standard. Puede especificar uno de ellos en el archivo del proyecto actualizando el valor de
<TargetFramework> . Las bibliotecas sin dependencias específicas de .NET Core, como WPF o Windows Forms, pueden beneficiarse de la elección de .NET Standard:
<TargetFramework>netstandard2.1</TargetFramework>
para que puedan ser utilizados por personas que llaman dirigidas a muchas plataformas .NET diferentes. Por otro lado, si la biblioteca usa una función que requiere .NET Core (por ejemplo, la API de la IU del escritorio de Windows), la biblioteca debería centrarse en .NET Core:
<TargetFramework>netcoreapp3.0</TargetFramework>
try-convert es una herramienta global que puede
instalar en su computadora y luego llamar desde la CLI:
C:\> try-convert -p <path to your project>
o
C:\> try-convert -w <path to your solution>
Como se mencionó anteriormente, si la herramienta try-convert no funciona en su caso, aquí están los materiales sobre cómo portar la aplicación manualmente.
VideoLa documentación
Ver también:
7 cursos gratuitos para desarrolladores