Presentación de .NET 5.0 Preview 6

La semana pasada lanzamos .NET 5.0 Preview 6. La versión contiene un pequeño conjunto de nuevas características y mejoras de rendimiento. La publicación .NET 5.0 Preview 4 está dedicada a lo que planeamos lanzar en .NET 5.0. La mayoría de las características están implementadas actualmente, pero algunas aún no están en su estado final. Esperamos que la versión sea completamente funcional con la Vista previa 8.



Puede  descargar .NET 5.0 Vista previa 6 , para Windows, macOS y Linux:





ASP.NET Core  y  EF Core  también fueron lanzados la semana pasada. Nota: EF Core 5.0 no admitirá .NET Standard 2.0 o .NET Framework. Lea  la publicación de lanzamiento de EF Core para obtener más información.



Debe usar  Visual Studio 2019 16.7  para trabajar con .NET 5.0. .NET 5.0 ahora es compatible con  Visual Studio para Mac . Instale la última  extensión de C # para usar .NET 5.0 con  Visual Studio Code .



Notas:









Actualización de Windows ARM64



Anunciamos soporte para Windows ARM64 en la Vista previa 4 . En ese momento, solo incluíamos aplicaciones de consola y ASP.NET Core en Windows ARM64. SDK Preview 6 ahora incluye soporte para Windows Forms. Esto significa que puede compilar y ejecutar aplicaciones de formularios Windows Forms en dispositivos Windows ARM64, tal como puede hacerlo en x64. Todavía estamos trabajando para agregar soporte WPF a Windows ARM64.



Puede ver una aplicación de Windows Forms de muestra ejecutándose en una computadora portátil ARM64 como se muestra a continuación.







Visual Studio 16.7 espera soporte para el depurador remoto de Visual Studio .NET para Windows ARM64. Esperamos que poco después de esto, aparezca el soporte para el depurador remoto de Visual Studio Code .NET. Para evitar confusiones, este soporte se aplica a ejecutar Visual Studio o Visual Studio Code en una computadora x64 y conectarse de forma remota a una aplicación .NET en ejecución en una computadora Windows ARM64. Además, Visual Studio Code agrega soporte para ARM64. Agregaremos soporte para la extensión C # y el depurador .NET que se ejecuta en la versión ARM64 de Windows de Visual Studio Code, sin embargo, las fechas aún no se conocen.



Windows Forms



Los usuarios de Visual Basic están acostumbrados a hacer que sus aplicaciones tengan una sola instancia (una instancia ejecutándose a la vez). Este comportamiento ahora está disponible a través de WindowsFormsApplicationBase.IsSingleInstance . Aquí hay una gran explicación para este comportamiento de Scott Hanselman.



El equipo agregó soporte de colapso al ListViewGroup. Este cambio facilita la administración de su formulario con múltiples ListViewGroups.



Y aqui esta el resultado:







Mejorando la calidad del código RyuJIT



El equipo de RyuJIT continúa realizando mejoras realmente importantes, vista previa por vista previa. No decepcionaron en la Vista previa 6. Veamos:







Continuamos mejorando el soporte para aplicaciones de un solo archivo en .NET 5. Nuestro objetivo es simplificar la publicación de la aplicación como un solo archivo para Windows, macOS y Linux. Ya estamos cerca. Cuando hablamos de esto por última vez en la Vista previa 4 , mencioné que las aplicaciones de "archivo único" de Windows requieren algunos archivos de tiempo de ejecución adicionales. Hemos agregado una nueva opción para incluir binarios nativos y cualquier contenido adicional (como imágenes) en un archivo. Estos archivos se extraerán en el primer lanzamiento. Las aplicaciones diseñadas para Linux y macOS no deben usar esta opción para los binarios nativos de tiempo de ejecución a menos que quieran usarla para contenido multimedia u otro contenido.



Limitaciones actuales:



  • Linux runtime- . ( Windows).
  • Linux , , IL.


-



Con los años, hemos visto muchos modelos de alojamiento para .NET en aplicaciones nativas. @rseanhall propuso e implementó un nuevo modelo nuevo para esto, que utiliza todas las funcionalidades de aplicación integradas proporcionadas por el nivel de hospedaje de aplicaciones .NET (en particular, carga de dependencias), al mismo tiempo que le permite llamar a un punto de entrada personalizado desde el código nativo. Esto es ideal para muchos escenarios, y está claro que se está convirtiendo en una técnica popular entre los desarrolladores que alojan componentes .NET de aplicaciones nativas.



Dos relaciones públicas principales:



  • Incluir llamada get_runtime_delegate desde el contexto de la aplicación
  • Implementación de hdt_get_function_pointer


Soporte de la plataforma



Hemos actualizado nuestra página de versión de SO compatible con .NET 5 para reflejar nuestros últimos planes para admitir la plataforma .NET 5.0. Por favor, dinos lo que piensas. ¿Qué nos estamos perdiendo?



Sabemos que el administrador de paquetes y el soporte de contenedores que ofrecemos no se enumeran en esta página. Esto debería ser arreglado. Planeamos agregar esta información antes del lanzamiento de .NET 5.0.



All Articles