Pronto habrá una nueva versión de .NET, con un nuevo conjunto de compiladores que promete un futuro multiplataforma.
por Simon Bisson
La próxima versión de la plataforma .NET está a la vuelta de la esquina . La nueva cadencia anual de lanzamientos convierte .NET 6 en el primer lanzamiento de soporte a largo plazo del .NET unificado. Eso lo convierte en un evento más importante que la mayoría, ya que es el primero en el que las organizaciones pueden confiar para usarlo como base de su estrategia de desarrollo.
Microsoft publicó recientemente su primera versión candidata , una de las dos que vendrán con una licencia de “puesta en marcha” que garantiza el soporte de Microsoft para las aplicaciones de producción. Este es siempre un gran paso. En este punto, lo que se había usado para prototipos y otras pruebas se usa a escala, revelando cualquier error. Es por eso que Microsoft ofrece soporte para que el equipo de .NET pueda ver los casos extremos que no pudo alcanzar en sus propias pruebas.
¿Debería comenzar a cambiar a .NET 6? Ciertamente, si ya está usando .NET 5, debería encontrar la migración relativamente fácil, ya que la nueva versión agrega muchas características nuevas. Las migraciones desde .NET Framework siguen siendo más difíciles, aunque .NET 6 agrega más características de compatibilidad. Aún así, hay suficiente diferencia entre las dos plataformas para que migrar el código sea un proyecto importante. Aun así, probablemente sea un buen momento para iniciar cualquier migración, con soporte disponible con un lanzamiento a largo plazo como objetivo.
Puede descargar el tiempo de ejecución actual y los instaladores de Microsoft ahora , con soporte de herramientas de desarrollo en las últimas versiones preliminares de Visual Studio 2022 (que deberían lanzarse junto con .NET 6 en .NETconf en noviembre). Una versión de Visual Studio 2022 para macOS compatible con .NET 6 se encuentra actualmente en versión preliminar privada .https://imasdk.googleapis.com/js/core/bridge3.482.0_en.html#goog_15385684931 second of 28 secondsVolumen 0%
Quitando las carátulas de un nuevo compilador .NET
Para la mayoría de nosotros, los lenguajes que usamos son nuestro principal punto de contacto para .NET y, al igual que las versiones anteriores, .NET 6 trae nuevas versiones de sus herramientas principales. Sin embargo, las partes más importantes de una nueva versión están bajo el capó de las herramientas que toman nuestro código y lo ejecutan en el hardware de destino, desde dispositivos ARM de bolsillo hasta sistemas masivos x64 en la nube multinúcleo.
Gran parte del trabajo en .NET 6 ha consistido en mejorar sus compiladores , trabajar en la optimización del código y utilizar la optimización guiada por perfiles dentro del proyecto para producir bibliotecas de tiempo de ejecución optimizadas. Quizás sea mejor considerarlo como un avance para .NET 7. Puede obtener el beneficio de la optimización guiada por perfil estático (PGO) en su código, pero aún no puede usarlo usted mismo. Al mismo tiempo, hay una herramienta PGO dinámica opcional integrada en el compilador .NET JIT. Es una buena forma de mejorar el rendimiento del código en ejecución , pero las optimizaciones se perderán entre ejecuciones.
Dynamic PGO aprovecha el soporte de .NET 6 para la compilación por niveles. Esto utiliza una pasada de compilación preliminar de Nivel 0 para crear rápidamente código no optimizado. Una vez que tenga esto, puede ver qué métodos se utilizan con más frecuencia, y luego se pueden optimizar en una pasada de compilador de Nivel 1, basándose en datos de ejecuciones anteriores. El código resultante tendrá una huella de memoria más grande, pero también será significativamente más rápido. La documentación de Microsoft ofrece ejemplos que tienen más del doble de velocidad que el código que no usa PGO dinámico.
Todas estas características son parte del nuevo compilador Crossgen2. Es una herramienta importante e independiente que funciona con .NET JIT para entregar código que se puede ejecutar en cualquier lugar donde haya un conjunto compatible de .NET. Esto permite que su código se compile para un entorno y luego se entregue a otro. Crossgen2 produce código listo para ejecutar, compilando un ensamblado completo antes de ejecutarlo. Aunque eso es ineficiente, es un comienzo para futuras versiones del compilador. Actualmente, admite conjuntos de instrucciones más antiguos, que aún se ejecutarán en hardware más nuevo, aunque han sido reemplazados por instrucciones más nuevas que aprovecharán el hardware moderno a escala de nube. Quizás sea mejor pensar en Crossgen2 como el primer paso a una nueva forma de construir y entregar código, una que mezcla JIT y compilación lista para ejecutar, pero una en la que no veremos el beneficio completo hasta el momento.
Cambio de pilas de red
Uno de los cambios más importantes en la red .NET es el soporte para HTTP / 3 y el protocolo QUIC . Esto mejorará el soporte para conexiones HTTP seguras, con seguridad de la capa de transporte (TLS) y Protocolo de datagramas de usuario (UDP) integrados para evitar el bloqueo de la conexión. Facilita la itinerancia de las conexiones entre cableadas, inalámbricas y móviles, ya que QUIC (Conexión rápida a Internet UDP) es independiente de la dirección de conexión subyacente. Eso hace que el roaming sea mucho más fácil, ya que las transacciones largas, como las descargas, pueden continuar funcionando incluso si cambia la conexión subyacente del dispositivo a Internet.
El soporte para el protocolo QUIC subyacente es importante por otras razones. La migración de .NET Framework a .NET Core que comenzó con .NET 5 ha dejado algunos componentes clave de .NET en el camino, incluido WCF, Windows Communication Foundation. Las API de WCF se utilizaron para crear aplicaciones orientadas a servicios en .NET, un modelo que es cada vez más importante con el cambio a aplicaciones nativas de la nube. Microsoft recomienda pasar a gRPC como una forma de implementar puntos finales de servicio, y está trabajando en una implementación basada en HTTP / 3. Este enfoque tiene mucho sentido para aplicaciones móviles y de borde donde las conexiones pueden cambiar entre Wi-Fi y celular dependiendo de la posición y las condiciones.
No es un gran paso pasar de HTTP / 2 a HTTP / 3 para gRPC, pero debería haber mejoras de rendimiento significativas, especialmente para dispositivos móviles e Internet de las cosas y otras implementaciones de borde. Puede experimentar con él ahora si habilita la compatibilidad con HTTP / 3 en su código y luego implementa una interfaz gRPC. El código del cliente debe negociar automáticamente una conexión HTTP / 3 si es compatible con el sistema operativo del host.
Con Windows y Linux obteniendo el soporte HTTP / 3 de .NET 6, no estará allí en macOS, ya que Apple no proporciona ninguna API QUIC. Sin embargo, dado que QUIC se está volviendo cada vez más popular, es probable que obtenga soporte con relativa rapidez. Mientras tanto, cualquier código que use gRPC HTTP / 3 también debe escribirse para responder a las llamadas estándar de gRPC a través de HTTP / 2.
Un .NET abierto
Otro desarrollo interesante en .NET 6 es la capacidad de crear un tiempo de ejecución que sea de código abierto demostrable. Para la mayoría de las distribuciones de Linux, las herramientas deben construirse utilizando herramientas de código abierto, lo que para .NET requiere un proceso de dos etapas. Para habilitar esto, Microsoft ahora puede entregar código fuente .NET en un tarball fuente como cualquier otro componente importante de Linux. Si bien este solía ser un proceso manual que a menudo retrasaba la distribución, ahora es una parte automatizada del proceso de compilación de .NET, lo que garantiza que el código de distribuciones de Linux como Red Hat esté sincronizado con las propias compilaciones de Microsoft.
La compatibilidad con archivos tar de código fuente es una señal importante del compromiso de Microsoft y .NET Foundation con un .NET abierto. Hay mucho trabajo en la última versión que proviene de fuera de Microsoft, aunque Redmond sigue siendo, con mucho, el mayor contribuyente. Pero Microsoft está utilizando sus blogs para llamar a los contribuyentes a sus bibliotecas y para hacer referencia a asociaciones con empresas como Red Hat. Tiene sentido que Microsoft apueste por lo abierto en .NET: debe apuntar a una gran cantidad de plataformas a medida que el entorno informático se expande y llegan nuevas arquitecturas, como los nuevos conjuntos de instrucciones de ARM.
Fuente: https://www.infoworld.com/article/3634600/under-the-hood-with-net-6.html
