Artículo
01/31/2019

Número especial de Connect(); de 2018

Volumen 33, número 13

.NET Core: Novedades de .NET Core 3.0

Por Scott Hunter; de 2018

En este artículo se describen tecnologías que se encuentran en versión preliminar. Toda la información está sujeta a cambios.

.NET Core 3.0 es la nueva versión principal de la plataforma .NET Core. En este artículo se describe la historia de .NET Core y se muestra cómo ha evolucionado desde que ofrecía compatibilidad básica con las cargas de trabajo de datos y web en la versión 1 hasta ser capaz de ejecutar cargas de trabajo web, de escritorio, aprendizaje automático, contenedores, IoT y mucho más en la versión 3.0.

.NET Core 1

El viaje de .NET Core comenzó hace algunos años, con la versión 1 en 2016, con el fin de crear la primera versión de .NET de código abierto y multiplataforma (Windows, macOS y Linux). La motivaron los clientes que solo podían usar marcos de código abierto y otros clientes que necesitaban ejecutar sus aplicaciones .NET en servidores Linux. Dado que .NET Core es multiplataforma, se diseñó para que todo se pudiera hacer desde la línea de comandos, sin necesidad de un IDE. Y, tras lo aprendido de los retos de compatibilidad de una versión de .NET Framework instalada globalmente, se diseñó con compatibilidad paralela. Por ejemplo, el marco se incluye como parte de la aplicación para que esta no dependa de que la máquina tenga un marco concreto instalado. La versión 1 se incluía con las versiones nuevas de ASP.NET y Entity Framework (EF) y, principalmente, estaba orientada a aplicaciones web.

.NET Core 2

Aunque la versión 1 permitía ejecutar .NET en nuevas plataformas, solo admitía un conjunto limitado de API de .NET. Para solucionar este problema, creamos.NET Standard, que especifica las API que debe implementar cualquier entorno en tiempo de ejecución de .NET para que el código y los archivos binarios se puedan compartir entre distintas versiones y plataformas de .NET. Con .NET Standard 2.0, agregamos más de 20 000 API a la especificación .NET Standard. La versión 2 de .NET Core se lanzó en junio de 2017 e incluía compatibilidad con .NET Standard 2.0. De este modo, se proporcionaba acceso a estas API. También introdujimos el paquete de compatibilidad de Windows, que es un paquete NuGet que incluye muchas API solo de Windows, como System.Drawing y System.DirectoryServices, entre otras. ASP.NET Core 2.0 incluye Razor Pages y SignalR, dos marcos que faltaban en .NET Core 1.0. Entity Framework Core es compatible con la carga diferida, una característica popular de Entity Framework. .NET Core 2 continuó con el objetivo de convertir .NET en uno de los marcos de pila completa más rápidos. El banco de pruebas de TechEmpower, que se ejecuta desde una compañía independiente, incluye .NET Core como n.º 7 en rendimiento de texto no cifrado sin procesar y n.º 6 en la prueba de Fortunes de rendimiento web y de datos, por delante de Java Servlet y Node.js (bit.ly/2PEE1l1).

.NET Core 3.0

.NET Core 3.0 es la nueva versión principal de la plataforma .NET Core. Incluye muchas características nuevas e interesantes, como la compatibilidad con aplicaciones de escritorio de Windows con Windows Forms (WinForms), Windows Presentation Foundation (WPF) y Entity Framework 6. En cuanto al desarrollo web, permite compilar aplicaciones web de lado cliente con C# mediante Razor Components (antes conocido como Blazor). También ofrece compatibilidad con C# 8.0 y .NET Standard 2.1.

Estamos agregando compatibilidad con escenarios de Internet de las cosas (IoT) en .NET Core 3.0. Ahora podrá programar pines de hardware (para controlar los dispositivos y leer datos de sensores) en Raspberry Pi y otros dispositivos similares, así como comunicarse mediante puertos serie en todos los sistemas operativos compatibles (por ejemplo, mediante Raspberry Pi o Arduino). También estamos agregando compatibilidad con dispositivos IoT para ARM64 en esta versión, a fin de complementar la funcionalidad existente de ARM32.

.NET Core 3.0 también es totalmente compatible con ML.NET, nuestro marco de aprendizaje automático de código abierto diseñado para desarrolladores de .NET. Usan ML.NET productos como Azure Machine Learning, Windows Defender e Ideas de diseño de PowerPoint. ML.NET permite agregar muchos escenarios populares de aprendizaje automático a las aplicaciones, como análisis de opiniones, recomendaciones, previsiones, clasificación de imágenes, etc. Más información en bit.ly/2OLRGRQ.

Recientemente, publicamos la primera versión preliminar de .NET Core 3.0. Para obtener más información acerca de .NET Core 3.0 y probar la versión preliminar, consulte aka.ms/netcore3preview1.

Escritorio (Windows Forms y WPF) y código abierto

WinForms y WPF son dos de los tipos de aplicaciones de .NET más populares y los usan millones de desarrolladores. .NET Core 3.0 ofrece compatibilidad con WinForms y WPF, lo que acerca el desarrollo para escritorios Windows a .NET Core. .NET Core siempre se ha centrado en el código abierto, y ambos marcos serán de código abierto en GitHub, junto con el resto de .NET Core. Por primera vez, los clientes podrán ver el desarrollo abierto de estos marcos e incluso podrán contribuir enviando problemas, corrigiendo errores o ayudando a desarrollar características nuevas en vivo en GitHub. La biblioteca XAML de WinUI también será de código abierto, y, con XAML Islands, podrá usar estos controles en aplicaciones de WinForms y WPF.

Muchas de las aplicaciones existentes de WinForms y WPF usan Entity Framework para acceder a los datos, por lo que Entity Framework 6 también será compatible con .NET Core.

Tal vez se pregunte por qué querría compilar aplicaciones de escritorio en .NET Core. Muy sencillo: le dará acceso a todos los avances de .NET Core. Puede compilar aplicaciones en la versión más reciente del marco sin tener que instalar .NET Core, y puede publicar tanto la aplicación como .NET Core en un único archivo .EXE. .NET Core se diseñó con un modelo paralelo en mente, por lo que puede tener varias versiones en un equipo y bloquear aplicaciones en la versión para la que se diseñaron. Gracias a este modelo paralelo, las API de .NET Core, incluidos WinForms y WPF, se pueden mejorar sin riesgo de interrumpir las aplicaciones.

ASP.NET Core 3

Sin embargo, .NET Core 3.0 no se centra únicamente en los equipos de escritorio. También hay una gran cantidad de nuevas y emocionantes características diseñadas para la Web. Echemos un vistazo a algunas de las características en que estamos trabajando.

Una pregunta común de los clientes es cómo tener una experiencia de RPC (como en .NET Remoting y Windows Communication Foundation) en .NET Core. Estamos contribuyendo en el proyecto gRPC (grpc.io) para garantizar que gRPC ofrezca una excelente compatibilidad para los desarrolladores de .NET.

Este año, iniciamos un experimento en desarrollo web del lado cliente mediante .NET al que denominamos Blazor. Blazor le permite escribir componentes de interfaz de usuario web que se ejecutan directamente en el explorador en un entorno en tiempo de ejecución de .NET basado en WebAssembly sin necesidad de escribir una sola línea de código JavaScript. Los componentes se crean mediante la sintaxis de Razor y, a continuación, se compilan junto con el código en ensamblados .NET normales. Después, los ensamblados y el entorno en tiempo de ejecución de .NET basado en WebAssembly se descargan en el explorador y se ejecutan solo mediante estándares web abiertos (sin necesidad de complementos ni de transpilación del código), tal y como se muestra en la Figura 1.

Figura 1 Desarrollo web del lado cliente con Blazor

Como alternativa, se pueden ejecutar los mismos componentes en el servidor mediante .NET Core, donde todas las interacciones de la interfaz de usuario y las actualizaciones de DOM se controlan mediante una conexión de SignalR, como se muestra en la Figura 2. Cuando se ejecutan los componentes, realizan el seguimiento de las actualizaciones que requiere DOM y las envían al explorador mediante la conexión SignalR que se aplicará. Los eventos de interfaz de usuario se envían al servidor con la misma conexión. Este modelo tiene varias ventajas: el tamaño de descarga es mucho menor, el código se centraliza en el servidor y se obtienen todas las características y ventajas de rendimiento de la ejecución en .NET Core.

Figura 2 Ejecución de componentes web de interfaz de usuario en el servidor mediante SignalR

Para .NET Core 3.0, estamos integrando el modelo de componentes de Blazor en ASP.NET Core. Este modelo de componentes integrados se denomina Razor Components. Razor Components habilita una nueva era de interfaces de usuario que admiten composición con ASP.NET Core y desarrollo web de pila completa con. NET. Inicialmente, para .NET Core 3.0, Razor Components se ejecutará en el servidor, como componentes enrutables independientes, o desde Razor Pages y vistas de Razor. Sin embargo, los mismos componentes también se pueden ejecutar del lado cliente en WebAssembly. En paralelo con el trabajo de .NET Core 3.0, vamos a seguir trabajando para admitir Razor Components en WebAssembly mediante el entorno en tiempo de ejecución de .NET basado en intérprete que tenemos previsto lanzar en una versión posterior. Más adelante, también tenemos previsto ofrecer compatibilidad con la compilación anticipada de código .NET en WebAssembly, que aportará mejoras significativas en el rendimiento en tiempo de ejecución.

EF Core 3.0

LINQ es una apreciada característica de .NET que permite escribir consultas de base de datos sin abandonar el lenguaje elegido. De este modo, aprovecha la información de tipo enriquecido para obtener comprobación de tipos en tiempo de compilación e IntelliSense. Pero LINQ también le permite escribir un número prácticamente ilimitado de consultas complicadas y eso siempre ha sido un gran reto para los proveedores de LINQ. EF Core soluciona este reto parcialmente al elegir qué partes de una consulta se pueden traducir a SQL y, a continuación, ejecutar el resto de la consulta en memoria. En algunas situaciones, esto puede ser deseable, pero en muchos otros casos, puede dar lugar a consultas poco eficientes que no se identifican hasta que la aplicación está en producción.

En EF Core 3.0, tenemos previsto hacer grandes cambios en el funcionamiento de la implementación de LINQ y en la forma de probarla a fin de hacerla más sólida (por ejemplo, para evitar la interrupción de consultas en versiones de revisiones), permitir que traduzca más expresiones correctamente a SQL, conseguir que genere consultas eficientes en más casos y evitar que las consultas altamente ineficientes pasen inadvertidas hasta producción.

Hemos estado trabajando en un proveedor de Cosmos DB para EF Core a fin de que los desarrolladores familiarizados con el modelo de programación de EF puedan orientarse fácilmente a Azure Cosmos DB como base de datos de aplicación. El objetivo es conseguir que algunas de las ventajas de Cosmos DB, como la distribución global, la disponibilidad AlwaysOn, la escalabilidad elástica y la baja latencia, sean aún más accesibles para los desarrolladores de .NET. El proveedor habilitará la mayoría de características de EF Core, como el seguimiento de cambios automático, las conversiones de valor y LINQ, con la API SQL de Cosmos DB.

Otras características que tenemos previsto incluir en EF Core 3.0 son las entidades de bolsas de propiedades (entidades que almacenan datos en propiedades indexadas, en lugar de propiedades normales), la capacidad de aplicar ingeniería inversa a las vistas de bases de datos para obtener tipos de consulta, y la integración con nuevas características de C# 8.0, como la compatibilidad con IAsyncEnumerable <T> y los tipos de referencia que aceptan valores NULL.

Somos conscientes de que la portabilidad a EF Core puede requerir un esfuerzo importante para muchas aplicaciones existentes que usan versiones anteriores de EF. Por este motivo, también estamos portando EF 6 para que funcione en .NET Core.

.NET Standard 2.1

Si usa .NET Standard, puede crear bibliotecas que funcionen en todas las implementaciones de. NET, no solo en .NET Core, sino también en Xamarin y Unity. En .NET Standard 1.x, solo se modelan las API comunes para las distintas implementaciones. Con .NET Standard 2.0, nos hemos centrado en facilitar que se pueda portar el código existente de .NET Framework a .NET Core, lo que dio como resultado no solo 20 000 API adicionales, sino también el modo de compatibilidad, que permite hacer referencia a bibliotecas de .NET Framework desde bibliotecas basadas en .NET Standard sin tener que volver a compilarlas. Para ambas versiones del estándar, prácticamente no hubo ningún componente nuevo, ya que todas las API eran API de .NET existentes.

Con .NET Standard 2.1, esto ha cambiado: hemos agregado unas 3000 API que, en su mayoría, son nuevas, y se introdujeron como parte del desarrollo de código abierto de .NET Core. Al agregarlas al estándar, las acercamos a todas las implementaciones de .NET Standard.

Entre las nuevas API, se encuentran las siguientes:

Span<T> En .NET Core 2.1, hemos agregado Span<T>, que es un tipo de matriz que permite representar la memoria administrada y no administrada de manera uniforme, y es compatible con la segmentación sin copiar. La mayoría de mejoras relacionadas con el rendimiento de .NET Core 2.1 se basan en Span<T>. Dado que permite administrar búferes de una manera más eficaz, puede ayudar a reducir asignaciones y copias. Para obtener más información acerca de este tipo, no olvide leer el excelente artículo de Stephen Toub sobre Span<T> (msdn.com/magazine/mt814808).
ValueTask y ValueTask<T> En .NET Core 2.1, la característica más importante implicó mejoras en nuestras bases para admitir escenarios de alto rendimiento (bit.ly/2HfIXob), lo que también incluyó mejorar la eficiencia de async/await. ValueTask<T> ya existe y permite devolver resultados si la operación se completa sincrónicamente sin tener que asignar ninguna tarea nueva. Con .NET Core 2.1, hemos mejorado esto aún más, y resulta útil tener una instancia de ValueTask correspondiente y no genérica que permita reducir las asignaciones incluso en los casos en que la operación se deba completar de un modo asíncrono, una característica que ya usan tipos como Socket y NetworkStream.
Adecuación general Puesto que .NET Core era de código abierto, hemos agregado muchas características pequeñas en bibliotecas de clase base, como System.HashCode, para combinar códigos hash o nuevas sobrecargas en System.String. Hay, aproximadamente, 800 miembros nuevos en .NET Core y prácticamente todos ellos se han agregado en .NET Standard 2.1.

Para obtener más información, consulte el anuncio de .NET Standard 2.1 en bit.ly/2RCW2fX.

C# 8.0

C# 8.0 es la próxima versión de C# y mejora el lenguaje de varias maneras principales. Los tipos de referencia que aceptan valores NULL ayudan a evitar excepciones de referencia NULL y a fomentar prácticas de programación null-safe. Puede optar por recibir advertencias de la característica al asignar valores NULL a variables o parámetros de, por ejemplo, cadena de tipo. Si quiere permitir valores NULL, debe indicarlo mediante un tipo de referencia que acepte valores NULL "string?".

Las secuencias asincrónicas hacen por las secuencias asincrónicas de datos lo que async/await hacía por los resultados asincrónicos únicos. Un nuevo tipo de marco IAsyncEnumerable<T> es la versión asincrónica de IEnumerable<T> y también se le pueden aplicar las instrucciones foreach y yield return:

public static async IAsyncEnumerable<T> FilterAsync<T>(
  this IAsyncEnumerable<T> source,
  Func<T, Task<bool>> predicate)
{
  await foreach (T element in source)
  {
    if (await predicate(element)) yield return element;
  }
}

Entre otras características, las implementaciones de miembros de la interfaz predeterminada permiten a las interfaces agregar nuevos miembros sin interrumpir los implementadores existentes. Las expresiones switch permiten una coincidencia de patrones más concisa. Además, los patrones pueden ser recursivos, lo que permite profundizar más en los valores de prueba. Para obtener más detalles sobre C# 8.0, consulte aka.ms/csharp8.

¿Cómo avanzarán .NET Framework y .NET Core?

.NET Framework es la implementación de .NET instalada en más de mil millones de equipos y, por tanto, debe ser tan compatible como sea posible. Por este motivo, se mueve a un ritmo más lento que .NET Core. Incluso las correcciones de errores y seguridad pueden provocar interrupciones en las aplicaciones, ya que las aplicaciones dependen del comportamiento anterior. Nos aseguraremos de que .NET Framework siempre admita los protocolos de red, los estándares de seguridad y las características de Windows más recientes.

.NET Core es la versión de código abierto, multiplataforma y de avance rápido de. NET. Debido a su naturaleza con paralelismo, puede asumir cambios que no podemos arriesgarnos a aplicar a .NET Framework. Esto significa que .NET Core obtendrá nuevas API y características del lenguaje con el tiempo que .NET Framework no recibirá.

Si tiene aplicaciones existentes de .NET Framework, no se sienta obligado a cambiar a .NET Core si no necesita aprovechar las características de .NET Core. Tanto .NET Framework como .NET Core se admitirán completamente, y .NET Framework siempre será parte de Windows. Incluso dentro de Microsoft, tenemos muchas grandes líneas de producto basadas en .NET Framework que permanecerán en .NET Framework. Pero, en adelante, .NET Core y .NET Framework contendrán características un poco diferentes.

Resumen

El lanzamiento de .NET Core 3.0 está previsto para la segunda mitad de 2019. Dispondrá de versiones de código abierto de WinForms y WPF para el desarrollo orientado a escritorios de Windows. También se incluirá Entity Framework 6. Además, ASP.NET Core, Entity Framework Core, .NET Standard y C# recibirán actualizaciones importantes. Esta versión de .NET Core se debería considerar seriamente para las nuevas aplicaciones de .NET. Para obtener más información, consulte aka.ms/netcore3preview1.

Estamos entusiasmados con el futuro de .NET y seguiremos agregando más cargas de trabajo a .NET Core. Le animo a probar la versión preliminar de .NET Core 3.0 y a enviarnos sus comentarios.

Scott Huntertrabaja para Microsoft como director de administración de programas para .NET supervisando el entorno en tiempo de ejecución, los marcos de trabajo, los lenguajes administrados (C#, F#, VB.NET) y las herramientas de .NET. Antes de esto, Hunter dirigió varias empresas emergentes, como Mustang Software y Starbase, donde se centró en una gran variedad de tecnologías, pero la programación web siempre ha sido su verdadera pasión.

Gracias a los siguientes expertos técnicos de Microsoft por revisar este artículo: Ankit Asthana, Damian Edwards, Richard Lander, Immo Landwerth, Beth Massi, Mads Torgersen

Comente este artículo en el foro de MSDN Magazine