05/06/2018Artículo original
Como ya os comentamos en directo durante la pasada DotNet2018, Microsoft ha anunciado la disponibilidad de .NET Core 2.1. Esta nueva versión incluye mejoras en el rendimiento, el runtime y las herramientas. También incluye una nueva forma de implementar herramientas como paquetes NuGet. Se agrega un nuevo e interesante tipo primitivo llamado Span
ASP.NET Core 2.1 y Entity Framework Core 2.1 van incluidas en esta actualización.
Puede descargar y comenzar con .NET Core 2.1, en Windows, macOS y Linux:
.NET Core 2.1 es compatible con Visual Studio 15.7, Visual Studio para Mac y Visual Studio Code.
Si lo tuyo es Docker, las imágenes correspondientes están disponibles en microsoft/dotnet tanto para .NET Core como para ASP.NET Core.
Puedes ver los detalles completos del lanzamiento en las notas de la versión de .NET Core 2.1.
.NET Core 2.1 es una versión de soporte a largo plazo (LTS), cosa que no era .NET Core 2.0. Esto significa que se dará soporte por parte de Microsoft durante tres años, por lo que se puede recomendar su uso desde ya.
De todos modos Microsoft dice que tienen la intención de enviar algunas actualizaciones significativas en los próximos 2 o 3 meses para estabilizar la versión por completo y empezar a dar el soporte LTS. Después de eso, las actualizaciones se orientarán a la seguridad, la confiabilidad y la adición de soporte de la plataforma (por ejemplo, Ubuntu 18.10).
Las principales ventajas de adoptar .NET Core 2.1 son:
- Soporte a largo plazo.
- Rendimiento y calidad superiores.
- Nuevo soporte de plataformas, como: Ubuntu 18.04, Alpine, ARM32…
- Es mucho más fácil administrar las versiones de .NET Core y ASP.NET Core en los archivos del proyecto y con la publicación de aplicaciones auto-contenidas.
En la actualidad .NET Core funciona en las siguientes plataformas:
- Windows Client: 7, 8.1, 10 (1607+)
- Windows Server: 2008 R2 SP1+
- macOS: 10.12+
- RHEL: 6+
- Fedora: 26+
- Ubuntu: 14.04+
- Debian: 8+
- SLES: 12+
- openSUSE: 42.3+
- Alpine: 3.7+
y se soportan los chips: x64 en Windows, macOS y Linux, x86 en Windows y ARM32* en Linux.
Herramientas de .NET Core
.NET Core ahora dispone de un nuevo mecanismo de despliegue y extensibilidad para herramientas. Esta nueva experiencia es muy similar e inspirada por las herramientas globales de NPM . Puedes crear tus propias herramientas globales echando un vistazo a las herramientas de ejemplo dotnetsay.
Las herramientas para .NET Core son aplicaciones de consola .NET Core que se empaquetan y adquieren como paquetes NuGet. Por defecto, estas herramientas son aplicaciones dependientes del framework, e incluyen todas sus dependencias NuGet. Esto significa que las herramientas .NET Core se ejecutan en todos los sistemas operativos y arquitecturas de procesador compatibles con .NET Core, con un único binario. Por defecto, el comando de dotnet tool install de la herramienta dotnet busca herramientas en NuGet.org. Puedes usar feeds NuGet propios también.
Actualmente, .NET Core Tools admite dos modelos de instalación:
- Instalación global, que requiere el parámetro -g o -global para instalar la herramienta. Las herramientas instaladas a nivel global se copian a una ubicación específica en tu perfil de usuario que está en el path del sistema, por lo que se pueden invocar de manera directa desde cualquier línea de comandos.
- Instalación Ad-hoc, que requiere utilizar el parámetro -tool-path. Las herramientas instaladas ad-hoc se copian en la ubicación que elijamos. Se pueden invocar a través de la ruta completa o puede agregar al path, lo que permite una configuración similar pero personalizada de la instalación global.
Aquí puedes encontrar una lista de herramientas para .Net Core mantenida por Nate McMaster.
Las siguientes herramientas DotNetCliReferenceTool que antes había que instalar por separado, se han convertido en herramientas “de serie”, así que mejor quita sus referencias del archivo de proyecto antes de actualizar a la versión 2.1:
- dotnet watch
- dotnet dev-certs
- dotnet user-secrets
- dotnet sql-cache
- dotnet ef
Grandes mejoras de rendimiento
El enfoque principal de Microsoft en esta versión ha sido quizá el de mejorar el rendimiento de la compilación .NET Core. Se ha mejorado mucho, especialmente en el caso de compilaciones incrementales. Estas mejoras se aplican tanto al comando dotnet build como a las compilaciones desde Visual Studio.
La siguiente imagen muestra las mejoras que se han obtenido en comparación con .NET Core 2.0 en el caso de los proyectos de referencia:
Como vemos, en el caso del proyecto grande se han conseguido mejoras de velocidad de compilación de hasta 10 veces menores.
En el caso del rendimiento en tiempo de ejecución las mejoras de rendimiento son también sustanciales. Puedes ver un estudio detallado en este artículo: Performance Improvements in .NET Core 2.1.
Del mismo modo se ha incrementado mucho el rendimiento en operaciones de red ya que se ha rescrito por completo la clase HttpClientHandler, en forma de la nueva clase SocketsHttpHandler. Esta es ahora es la implementación por defecto que se usa para HttpClient. La mayor ventaja de SocketsHttpHandler es el rendimiento. Es mucho más rápido que la implementación existente. También elimina las dependencias específicas de la plataforma y permite un comportamiento uniforme en todos los sistemas operativos.
Span <T>, Memory <T> y similares
Estamos entrando en una nueva era de informática eficiente y de alto rendimiento con .NET, con la introducción de Span
En este artículo de Stephen Toub puedes conocer Span
Compresión Brotli
Brotli es un algoritmo de compresión sin pérdidas, de propósito general, que comprime datos tan bien o mejor que los mejores métodos de compresión de uso general actualmente disponibles. Es similar en velocidad a deflate, pero ofrece una mayor compresión. Brotli se define en la RFC 7932. La mayoría de los navegadores web, los principales servidores web y algunos CDN (Content Delivery Networks) admiten la codificación y transmisión de datos utilizando Brotli. La implementación de .NET Core de Brotli se basa en el código C proporcionado por Google en google/brotli.
Nuevas API de criptografía
Se han realizado las muchas mejoras en las API de criptografía .NET Core, entre las que cabe destacar:
- Nuevas API SignedCms – System.Security.Cryptography.Pkcs.SignedCms ahora está disponible en el paquete System.Security.Cryptography.Pkcs . La implementación de .NET Core está disponible para todas las plataformas .NET Core y tiene paridad con la clase de .NET Framework.
- Nueva sobrecarga de X509Certificate.GetCertHash para SHA-2 – Las nuevas sobrecargas para X509Certificate.GetCertHash y X509Certificate.GetCertHashString aceptan un identificador de algoritmo hash para permitir que los llamantes obtengan valores de huella digital de certificado utilizando algoritmos distintos a SHA-1.
- Nuevo API de criptografía basada en Span<T> – Las API basadas en la nueva clase están disponibles para hashing, HMAC, generación de números aleatorios (criptográficos), generación de firmas asimétricas, procesamiento de firmas asimétricas y encriptación RSA, con la consiguiente mejora de rendimiento y uso de memoria.
- Mejoras de rendimiento en Rfc2898DeriveBytes – La implementación de Rfc2898DeriveBytes (PBKDF2) es aproximadamente un 15% más rápida, ya que se ha utilizado Span<T>.
- Añadido static RandomNumberGenerator.Fill – El método estático RandomNumberGenerator.Fill rellenará un Span<T> con valores aleatorios utilizando el CSPRNG preferido por el sistema, y no requiere que la persona que llama administre la vida útil de un recurso IDisposable.
Paquete de compatibilidad de Windows
Cuando transfiramos código existente desde .NET Framework a .NET Core, puede usar el Paquete de compatibilidad de Windows. Éste proporciona acceso a 20,000 API adicionales a las que están disponibles de base en .NET Core. Esto incluye System.Drawing, EventLog, WMI, Contadores de rendimiento e incluso Servicios de Windows. Puedes leer el artículo Announcing the Windows Compatibility Pack for .NET Core para obtener más información sobre este asunto.
Compilación escalonada
En esta versión se ha agregado una versión preliminar de una nueva y emocionante capacidad para el tiempo de ejecución llamada compilación escalonada. Se trata de una manera de conseguir que el runtime de .NET Core utilice de forma más adaptativa el compilador Just-In-Time (JIT) para obtener un mejor rendimiento.
El desafío básico para los compiladores de JIT es que el tiempo de compilación es parte del tiempo de ejecución de la aplicación. Producir un mejor código nativo generalmente significa pasar más tiempo optimizándolo. Pero si una determinada parte del código solo se va a ejecutar una vez (o unas pocas veces), el compilador podría dedicar más tiempo a optimizarla que el tiempo que gastaría ejecutando la versión no optimizada, por lo que es absurdo hacerlo en este tipo de fragmentos de código.
Con la compilación escalonada, el compilador primero genera código lo más rápido posible, con solo optimizaciones mínimas (primer nivel). Luego, cuando detecta que ciertos métodos se ejecutan mucho, produce una versión más optimizada de esos métodos (segundo nivel) que se utilizarán en lugar de la compilación original. La compilación de segundo nivel se realiza en paralelo, lo que elimina la tensión existente entre las velocidades de compilación rápidas y la producción de código óptimo. Este modelo se puede llamar genéricamente Optimización adaptativa.
Puedes probar la compilación escalonada estableciendo una variable simple de entorno:
COMPlus_TieredCompilation = "1"
Puedes habilitarla para una aplicación concreta configurando la propiedad TieredCompilation, como puede ver en este proyecto.
SourceLink
SourceLink es un sistema que habilita experiencias de depuración de los binarios .que distribuimos o consumimos que se asemejan a si tuviésemos el código fuente disponible. Necesia que dispongamos de información de SourceLink producida por el compilador, y depuradores que la soporten. El depurador de Visual Studio ya es compatible con SourceLink, comenzando con Visual Studio 2017 15.3. Se ha agregado soporte para generar información de SourceLink para símbolos, binarios y paquetes NuGet en el SDK de .NET Core 2.1.
Puedes comenzar a producir información de SourceLink siguiendo el ejemplo en dotnet/sourcelink . Puedes ver cómo está habilitada en este proyecto.
El objetivo de Microsoft con esto es permitir que cualquiera pueda construir Las bibliotecas NuGet para proporcionar depuración de fuentes para sus usuarios casi sin esfuerzo.
La siguiente captura de pantalla muestra la depuración de un paquete NuGet al que hace referencia una aplicación, con la fuente descargada automáticamente desde GitHub y utilizada por Visual Studio 2017:
Publicación de aplicaciones autocontenidas
dotnet publish ahora es capaz de publicar aplicaciones autocontenidas que incluyen en el ejecutable una versión del runtime concreta. Cuando publiquemos una aplicación autónoma con el nuevo SDK, ésta incluirá la última versión del runtime conocida por ese SDK. Gracias a esto no es necesario disponer de .NET Core en la máquina de los usuarios. Se obtiene un ejecutable (de tamaño considerable, eso sí), que es lo único que se necesita distribuir y funcionará sin problema en todos los equipos.
Docker
Las imágenes de Docker para .NET Core 2.1 están disponibles en microsoft/dotnet en Docker Hub . Se han consolidado el conjunto de repositorios de Docker Hub que utiliza Microsoft para .NET Core y ASP.NET Core. A partir de ahora se utilizará microsoft/dotnet como el único repositorio en el que Microsoft publicará imágenes de .NET Core 2.1 y versiones posteriores.
Se han añadido un conjunto de variables de entorno a las imágenes .NET Core para que sea más fácil alojar sitios ASP.NET Core con cualquier imagen de .NET Core y para habilitar el dotnet watch en las imágenes del contenedor del SDK sin necesidad de configuración adicional.
Los ejemplos de .NET Core Docker se han movido al repositorio dotnet/dotnet-docker de GitHub, y se han actualizado para .NET Core 2.1. Se han añadido nuevos ejemplos, incluido el alojamiento de imágenes ASP.NET Core con Docker a través de HTTPS .
Más detalles aquí.
Compatibilidad de .NET Core 2.1
.NET Core 2.1 es una versión altamente compatible. Las aplicaciones .NET Core 2.0 se ejecutarán en .NET Core 2.1 en ausencia de .NET Core 2.0. Este comportamiento de “upgradde” de versión del runtime solo se aplica a revisiones menores. Es decir, una aplicación .NET Core 1.1 no hará el salto a 2.0, lógicamente, ni tampoco se pasará en el futuro de .NET Core 2.0 a 3.0 automáticamente. Sin embargo si compilamos una aplicación para .NET Core 2.1 y en el futuro sale .NET Core 2.2 y ésta se ejecuta con esta versión del runtime, no hará falta hacer nada para que lo utilice.
Soporte de instalación de Early Snap
Microsoft ha llevado .NET Core a Snap . Se trata de una tecnología de instalación y aislamiento de aplicaciones muy interesante, pensando sobre todo en dispositivos de Internet de las Cosas (IoT). Las instalaciones Snap funcionan bien en sistemas basados en Debian pero en otras distribuciones Linux como Fedora todavía presentan problemas que Microsoft está intentado solucionar.
En resumen
.NET Core 2.1 es un gran paso adelante para la plataforma. Se ha mejorado muy significativamente el rendimiento, se han añadido muchas APIs así como una nueva manera de crear herramientas para la plataforma. También se ha dado soporte para nuevas distribuciones de Linux y, sobre todo, para ARM32, otro tipo de arquitectura de CPU. Esta versión amplía los lugares donde puede usar .NET Core y la convierte en una plataforma mucho más eficiente en todos ellos.
.NET Core 2.1 está también disponible en Azure App Service.
Post basado en el anuncio oficial del lanzamiento por parte de Microsoft.
