Se anunció .NET 5

Hoy Microsoft ha anunciado en el Build 2019 que la próxima release después de .NET Core 3 va a ser .NET 5. Esta va a ser la proxima gran release en la familia .NET.

De ahora en más solamente va a haber un solo .NET, y vamos a ser capaces de utilizarlo en Windows, Linux, macOS, iOS, Android, tvOS, watchOS, Web Assembly y más.

Se van a anunciar nuevas APIs de .NET, nuevas capacidades para la runtime, y características del lenguaje como parte de .NET 5

Una plataforma unificada

Desde la creación del proyecto .NET Core, se han agregado más de 5 mil APIs del .NET Framework a esta nueva plataforma. .NET Core 3.0 cierra mucho de los huecos que quedaban respecto a .NET Framework 4.8 agregando Windows Forms, WPF y Entity Framework 6. .NET 5 sigue sobre esta línea de trabajo tomando lo mejor de .NET Core y lo mejor de Mono para crear una sola plataforma que podamos usar para todo nuestro código .NET.

Microsoft tiene la intención de lanzar .NET 5 en Noviembre de 2020 con la primera versión preview lanzada durante el primer semestre de 2020. Se va a soportar en futuras actualizaciones de Visual Studio 2019, Visual Studio para Mac y Visual Studio Code.

.NET 5 = .NET Core vNext

.NET 5 es el siguiente paso con .NET Core. El proyecto busca mejorar .NET de varias maneras clave:

• Producir una sola runtime .NET y un solo framework que se pueda usar en todos lados y que tenga el mismo comportamiento y experiencia de desarrollo.
• Expandir las características de .NET tomando lo mejor de .NET Core, .NET Framework, Xamarin y Mono
• Construir un producto a partir de una sola base de código que los desarrolladores (de Microsoft y de la comunidad) puedan trabajar y expandir juntos y que mejore todos los escenarios.

Este nuevo proyecto y dirección son un cambio rotundo en .NET. Con .NET 5, nuestro código y nuestros archivos de proyecto se van a ver y sentir igual sin importar el tipo de aplicación que estemos construyendo. Vamos a tener acceso a la misma runtime, API y capacidades del lenguaje en cada aplicación. Esto incluye mejoras de performance que se commitean al corefx practicamente todos los días.

Todo lo que amamos sobre .NET Core va a continuar existiendo:

• Open Source y orientado a la comunidad en GitHub
• Implementación multiplataforma
• Soporte para capacidades especificas de la plataforma como Windows Forms y WPF en y enlaces nativos para cada plataforma con Xamarin
• Alto rendimiento
• Instalación Side-by-side
• Pequeños archivos del proyecto (estilo SDK)
• Potente interfaz de línea de comando (CLI).
• Integración con Visual Studio, Visual Studio para Mac y Visual Studio Code.

Esto es lo que traerá de nuevo:

• Vas a tener más elección sobre la runtime (ver más abajo).
• La interoperabilidad con JAVA va a estar disponible para todas las plataformas.
• La interoperabilidad con Objective-c y Swift va a estar disponible para múltiples sistemas operativos.
• La CoreFX se va a extender para soportar compilación estática de .NET (AOT), menor consumo de recursos y soporte para aún más sistemas operativos.

.NET Core 3.0 va a ser lanzado durante septiembre, .NET 5 en Noviembre de 2020, y después la idea es que salga una versión nueva de .NET una vez cada año, en noviembre:

Microsoft se está saltando la versión 4 porque esto confundiría a los usuarios que estan familiarizados con el .NET Framework, el cual ha venido usando la serie 4.X durante mucho tiempo. Además, querían comunicar que .NET 5 es el futuro de la plataforma .NET.

Además estan aprovechando para simplificar el nombre. Si solamente habrá un solo .NET de ahora en más, no necesitan agregar la palabra “Core” para aclarar. El nombre más corto es una simplificación y también comunica que .NET 5 tiene capacidad y comportamientos uniformes.

Experiencias de runtime

Mono es la implementación multiplataforma original de .NET. Empezó como una alternativa al .NET Framework y después fue haciendo una transición a dispositivos móviles que usen iOS y Android. Mono es la runtime que se utiliza como parte de Xamarin.

Core CLR es la runtime que se usa como parte de .NET Core. Se ha creado principalmente para soportar aplicaciones en la nube, incluyendo los servicios más grandes en Microsoft y ahora también se usa en el escritorio de Windows, IoT y aplicaciones de machine learning.

Si las ponemos juntas, la runtime de .NET Core y la de Mono tienen muchas similaridades (ambas son runtimes de .NET después de todo) pero también tienen capacidades únicas valiosas. Tiene sentido hacer que sea posible que podamos elegir la experiencia de runtime que quieramos. Microsoft está en el proceso de hacer que CoreCLR y Mono sean remplazos directos uno con el otro. La idea es que sea simple cambiar entre las diferentes opciones de runtime.

Las siguientes secciones describen los principales puntos que Microsoft está planeando para .NET 5. Proveen una vista clara de como planeamos evolucionar dos runtimes de manera individual, y también de manera conjunta.

Alto rendimiento y alta productividad

Desde el inicio de los tiempos, .NET ha dependido de que un compilador just-in-time (JIT) se tradujera a un lenguaje intermedio para optimizar el código de máquina. Desde ese momento, se ha construido una runtime JIT lider en la industria que es capaz de conseguir un alto rendimiento y también permitir que la experiencia de desarrollo hagan que la programación sea fácil y rápida.

Las JIT son la mejor opción para aplicaciones cloud que se ejecutan durante mucho tiempo y escensarios de cliente. Pueden generar código cuyo destino es una configuración específica de maquina incluyendo instrucciones de CPU específicas. Una JIT puede incluso regenerar métodos en tiempo de ejecución, una técnica usada para hacer un JIT rápido y que al mismo tiempo produce una versión del código altamente optimizada si el método en cuestión se vuelve muy frecuente.

Los esfuerzos de Microsoft para hacer que ASP.NET Core corra más rápido en los benchmarks de techempower es un buen ejemplo del poder de la compilación JIT y las inversiones en la CoreCLR. Los esfuerzos para fortificar .NET Core en los contenededores también muestran la habilidad de la runtime para adaptarse a ambientes con restricciones.

Las herramientas de desarrollo son otra cosa en la que la JIT brilla, tales como el comando dotnet watch o el “editar y continuar”. La posibilidad de editar código, compilarlo y cargarlos varias veces en el mismo proceso necesita que sea muy rápido.

Los desarrolladores usando .NET Core o .NET Framework han dependido principalmente en JIT. Como resultado esta experiencia debería resultarnos familiar.

La experiencia por defecto para la mayoría de las cargas de trabajo de .NET 5 va a ser seguir usando la CoreCLR con JIT. Las dos excepciones notable son iOS y Blazor (Web Assembly) dado que ambos requieren compilación antes de tiempo (AOT).

Inicio rápido, bajo consumo de recursos y memoria

El proyecto Mono ha pasado mucho de su esfuerzo enfocado en plataformas móviles y consolas de videojuego. Una capacidad clave del resultado del proyecto es un compilador AOT para .NET, basado en el lider de la insdustria el compilador LLVM. El compilador AOT de mono nos permite que el código .NET se ejecute en un solo ejecutable nativo, que pueda ejecutarse en una máquina, como el código C++. Las aplicaciones compiladas con AOT pueden ejecutarse de manera eficiente en lugares pequeños, y intercambia rendimiento por tiempo de inicio si hiciera falta.

El proyecto Blazor ya está utilizando el compilador Mono AOT. Será uno de los primeros proyectos en hacer la transición a .NET 5.

Hay dos tipos de soluciones AOT:

• Soluciones que requieren el 100% de la compilación en AOT.
• Soluciones que la mayoría del código es AOT pero hay un JIT o un interprete para patrones de código que no son muy amigables con AOT (como generics).

El compilador Mono AOT soporta ambos casos. El primer tipo de AOT se requiere para iOS y algunas consolas de juego. Por lo general por razones de seguridad. El segundo es la elección preferida dado que ofrece los beneficios de AOT sin sus desventajas.

.NET Native es el compilador AOT que se usa para las aplicaciones Windows UWP y es un ejemplo del primer tipo de AOT que se lista más arriba. Con esta implementación particular, limitaron las APIs de .NET y las capacidades que podemos usar. Esta experiencia les ha llevado a aprender que las soluciones AOT necesitan el espectro completo de APIs .NET y patrones.

La compilación AOT va a seguir siendo requerida para iOS, web assembly y algunas consolas de videojuego. Van a hacer que la compilación AOT sea una opción para aquellas aplicaciones que corran en algún aparato, requieran inicio más rápido o bajo consumo de recursos.

Experiencias que se superponen

Es crítico que se continue moviendo hacia una única plataforma desde el lado del tiempo de inicio, rendimiento, uso de memoria, confiabilidad y diagnóstico. Al mismo tiempo tambien tiene sentido que los esfuerzos se enfoquen. Van a invertir más en el rendimiento y la confiabilidad de la CoreCLR mientras al mismo tiempo en mejorar el tiempo de inicio y la reducción de tamaño con el compilador Mono AOT. Rendimiento y confiabilidad van juntos como lo son tiempo de inicio y reducción de tamaño.

Mientras que hay algunas características que dan sentido a hacer diferentes inversiones hay otras que no.

Las capacidades diagnóstico tienen que ser las mismas a través de todo .NET 5, tanto para los diagnósticos funcionales como los de rendimiento. Esto es importante para soportar los mismos chips y sistemas operativos (con la excepción de iOS y web assembly).

Van a continuar optimizando .NET 5 para cada escenario de carga de trabajo, según esto tenga setnido. Hay un mayor enfasis en optimizaciones, particularmente cuando varias cargas de trabajo tienen las mismas necesidades superpuestas.

Todas las aplicaciones .NET 5 van a usar el Framework CoreFx. Se van a asegurar que el CoreFX funcione bien en los lugares donde hoy en día no se usa que es principalmente Xamarin y las librerías del lado del cliente de Blazor. Todas las aplicaciones de .NET 5 van a poder ser compiladas con la .NET Cli lo que nos asegura que vamos a tener herramientas de línea de comando comunes para todos los proyectos.

C# va a avanzar en conjunto con .NET 5. Los desarrolladores que escriben aplicaciones .NET 5 van a tener acceso a la ultima versión de C# con todas sus cracterísticas.

Webforms queda afuera

Una cosa que se desprende de estos nuevos anuncios, a partir de que se dijera de que el Framework 4.8 va a ser la última versión de .NET Framework es que WebForms queda afuera de .NET 5. Esto se debe a que las librerías System.Web de las que WebForms depende están muy ligadas a Windows Server y a IIS lo que dificulta su escritura tanto para hacerlo multiplataforma como para adaptarlos a plataformas más modernas.

El nacimiento del proyecto

El equipo técnico de Microsoft se juntó en Diciembre de 2018 en Boston para arrancar este proyecto. Los lideres de diseñ o de los equipos .NET (Mono/Xamarin y .NET Core) y también de Unity presentaron varias capacidades técnicas y direcciones arquitectónicas.

Ahora estan avanzando con este proyecto como un solo equipo y con un solo conjunto de entregables. Desde Diciembre, han hecho un monton de progreso en algunos proyectos:

• Definieron una capa mínima que define la runtime y el código administrado con el objetivo de hacer el 99% del código comun de la CoreFX.
• MonoVM ahora puede usar CoreFX y todas sus liberías de clases.
• Corrieron todos los tests de CoreFX en la MonoVM usando la implementación de la CoreFX.
• Ejecutaron aplicaciones ASP.NET Core 3.0 en la MonoVM.
• Ejecutaron MonoDevelop y luego Visual Studio para Mac en la CoreCLR.

Mover a una sola implementación de .NET plantea preguntas importantes. ¿Cuál va a ser el target framework? ¿Las reglas de compatibilidad de NuGet serán las mismas? ¿Qué cargas de trabajo deben ser soportadas por .NET 5 desde el día 1? ¿Cómo va a funcionar escribir código para una arquitectura específica? ¿.NET Standard todavía es necesario? El equipo de Microsoft esta trabajando en estos asuntos y pronto estarán compartienod documentos de diseño para que la comunidad pueda leer y proveer retroalimentación.

Cerrando

El proyecto .NET 5 es un cambio de dirección importante y emocionante. Vamos a ver como .NET se hace más simple pero también más amplio, con más capacidades y utilidad. Todas las características de desarrollo nuevas van a ser parte de .NET 5, incluyendo nuevas versiones de C#.

Vamos a vivir un futuro más brillante en el que podemos usar las mismas APIs de .NET y lenguajes para apuntar a un rango amplio de tipos de aplicación, sistemas operativos y arquitecturas de chip. Va a ser más facil que hagamos cambios a nuestras configuraciones de compilación para compilar nuestras aplicaciones de manera diferente en Visual Studio, Visual Studio para Mac, Visual Studio Code, Azure DevOps o la línea de comandos.