En septiembre, lanzamos la compatibilidad con .NET Core para crear aplicaciones de escritorio de Windows, incluidos WPF y Windows Forms. Desde entonces, nos ha encantado ver a tantos desarrolladores compartir sus historias sobre la migraci贸n de aplicaciones de escritorio (y bibliotecas de control) a .NET Core. Constantemente escuchamos historias de desarrolladores de escritorio .NET Windows que impulsan su negocio con WPF y Windows Forms, especialmente en escenarios donde el escritorio brilla, incluyendo:
- Aplicaciones de formularios densos en UI sobre datos (FOD)
- IU de baja latencia receptiva
- Aplicaciones que deben ejecutarse sin conexi贸n / desconectadas
- Aplicaciones con dependencias en controladores de dispositivos personalizados
Este es solo el comienzo para el desarrollo de aplicaciones de Windows en .NET Core. Siga leyendo 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 que se construye sobre .NET Core) ser谩 el futuro de .NET. Estamos comprometidos a admitir .NET Framework en los a帽os venideros, sin embargo, no recibir谩 nuevas funciones, solo se agregar谩n a .NET Core (y eventualmente .NET 5). Para mejorar las pilas de escritorio de Windows y permitir que los desarrolladores de escritorio .NET se beneficien de todas las actualizaciones del futuro, llevamos Windows Forms y WPF a .NET Core. Seguir谩n siendo tecnolog铆as exclusivas de Windows porque existen dependencias estrechamente acopladas a las API de Windows. Pero .NET Core, adem谩s de ser 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 a .NET Core y en el futuro a .NET 5. Un buen ejemplo aqu铆 es C # 8 que estuvo disponible en .NET Core 3.0. Adem谩s, las versiones .NET Core de Windows Forms y WPF se convertir谩n en parte de la plataforma .NET 5. Entonces, al portar su aplicaci贸n a .NET Core hoy, los est谩 preparando para .NET 5.
Adem谩s, .NET Core brinda flexibilidad de implementaci贸n para sus aplicaciones con nuevas opciones que no est谩n disponibles en .NET Framework, como:
- Despliegue de lado a lado. Ahora puede tener m煤ltiples versiones de .NET Core en la misma m谩quina y puede elegir a qu茅 versi贸n debe apuntar cada una de sus aplicaciones.
- Despliegue aut贸nomo. Puede implementar la plataforma .NET Core con sus aplicaciones y volverse completamente independiente de su entorno de usuarios finales: su aplicaci贸n tiene todo lo que necesita para ejecutarse en cualquier m谩quina con Windows.
- Tama帽os de aplicaci贸n m谩s peque帽os. En .NET Core 3 presentamos una nueva caracter铆stica llamada enlazador (tambi茅n conocida como trimmer), que analizar谩 su c贸digo e incluir谩 en su implementaci贸n aut贸noma solo aquellos ensamblados de .NET Core que sean necesarios para su aplicaci贸n. De esa forma, se recortar谩n todas las partes de la plataforma que no se usen para su caja.
- Archivos individuales .exe. Puede empaquetar su aplicaci贸n y la plataforma .NET Core en un solo archivo .exe.
- Rendimiento mejorado en tiempo de ejecuci贸n. .NET Core tiene muchas optimizaciones de rendimiento en comparaci贸n con .NET Framework. Cuando piensa en el historial de .NET Core, creado inicialmente para cargas de trabajo web y de servidor, ayuda a comprender si su aplicaci贸n puede ver beneficios notables de las optimizaciones de tiempo de ejecuci贸n. Espec铆ficamente, las aplicaciones de escritorio con grandes dependencias en las operaciones de E / S de archivos, redes y bases de datos probablemente ver谩n mejoras en el rendimiento para esos escenarios . Algunas 谩reas en las que puede que no note muchos cambios son en el rendimiento de representaci贸n de la interfaz de usuario o el rendimiento de inicio de la aplicaci贸n.
Al establecer las propiedades
<PublishSingleFile> ,
<RuntimeIdentifier> y
<PublishTrimmed> en el perfil de publicaci贸n, podr谩 implementar una aplicaci贸n aut贸noma 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谩 mucha diferencia entre las versiones .NET Framework y .NET Core de WPF y Windows Forms. Una parte de nuestro esfuerzo fue proporcionar una paridad funcional entre estas plataformas en el 谩rea de escritorio y mejorar la experiencia de .NET Core en el futuro. Las aplicaciones WPF son totalmente compatibles con .NET Core y est谩n listas para su uso, mientras estamos trabajando en actualizaciones y mejoras menores. Para Windows Forms, la parte de tiempo de ejecuci贸n est谩 totalmente portada a .NET Core y el equipo est谩 trabajando en el Dise帽ador de Windows Forms. Estamos planeando tenerlo listo para el cuarto trimestre de 2020 y, por ahora, puede consultar la versi贸n preliminar del dise帽ador en
Visual Studio 16.4 Preview 3 o posterior. No olvide establecer la casilla de verificaci贸n 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 es limitada por ahora ya que el trabajo est谩 en progreso.
Rompiendo cambios
Hay algunos
cambios importantes entre .NET Framework y .NET Core, pero la mayor铆a del c贸digo relacionado con Windows Forms y las 谩reas de WPF se transfiri贸 a Core tal como est谩. Si estaba utilizando componentes como WCF Client, Code Access Security, App Domains, Interop y Remoting, necesitar谩 refactorizar su c贸digo si desea cambiar a .NET Core.
Otra cosa a tener en cuenta: las rutas de salida predeterminadas en .NET Core son diferentes de en .NET Framework, por lo que si tiene algunas suposiciones en su c贸digo sobre la estructura de archivos / carpetas de la aplicaci贸n en ejecuci贸n, entonces probablemente fallar谩 en el tiempo de ejecuci贸n.
Adem谩s, hay cambios en la forma de configurar las caracter铆sticas .NET. .NET Core en lugar del archivo
<something>.runtimeconfig.json usa el archivo
<something>.runtimeconfig.json que viene con una aplicaci贸n y tiene el mismo prop贸sito general e informaci贸n similar. Algunas configuraciones como
system.diagnostics ,
system.net o
system.net no son compatibles, por lo que un archivo de configuraci贸n de la aplicaci贸n no se cargar谩 si contiene alguna de estas secciones. Este cambio afecta al sistema, el seguimiento de
System.Diagnostics y los escenarios de clientes WCF que com煤nmente se configuraron utilizando la configuraci贸n XML anteriormente. En .NET Core necesitar谩 configurarlos en c贸digo. Para cambiar los comportamientos sin volver a compilar, considere configurar el rastreo y los tipos de WCF utilizando valores cargados desde una fuente
Microsoft.Extensions.Configuration o desde
appSettings .
Puede encontrar m谩s informaci贸n sobre las diferencias entre .NET Core y .NET Framework en la
documentaci贸n .
Empezando
Mira estos breves tutoriales en video:
Portado de .NET Framework a .NET Core
En primer lugar, ejecute el
Analizador de portabilidad y, si es necesario, actualice su c贸digo para obtener una compatibilidad del 100% con .NET Core. Aqu铆 hay
instrucciones sobre el uso del analizador de portabilidad . Recomendamos utilizar un control de origen o hacer una copia de seguridad de su c贸digo antes de realizar cambios en su aplicaci贸n en caso de que la refactorizaci贸n no se realice de la manera deseada y decida volver a su estado inicial.
Cuando su aplicaci贸n es totalmente compatible con .NET Core, est谩 listo para portarla. Como punto de partida, puede probar una 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. Tampoco 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 su soluci贸n tiene proyectos que la herramienta rechaza o no puede convertir, deber谩 realizar el puerto a mano. No se preocupe, tenemos muchos tutoriales sobre c贸mo hacerlo (al final de esta secci贸n).
La herramienta try-convert intentar谩 migrar sus archivos de proyecto de estilo antiguo al nuevo estilo SDK y volver a dise帽ar los proyectos aplicables a .NET Core. Para sus bibliotecas, dejamos que haga una llamada con respecto a la plataforma: el clima al que le gustar铆a apuntar .NET Core o .NET Standard. Puede especificarlo en su archivo de proyecto actualizando el valor de
<TargetFramework> . Las bibliotecas sin dependencias espec铆ficas de .NET Core como WPF o Windows Forms pueden beneficiarse de la orientaci贸n de .NET Standard:
<TargetFramework>netstandard2.1</TargetFramework>
para que puedan ser utilizados por las personas que llaman a muchas plataformas .NET diferentes. Por otro lado, si una biblioteca usa una caracter铆stica que requiere .NET Core (como las API de IU de escritorio de Windows), est谩 bien que la biblioteca apunte a .NET Core:
<TargetFramework>netcoreapp3.0</TargetFramework>
try-convert es una herramienta global que puede
instalar en su m谩quina, luego puede llamar desde 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 funcion贸 para usted, aqu铆 hay materiales sobre c贸mo portar su aplicaci贸n a mano.
VideosDocumentaci贸n