Hoy anunciamos .NET Core 3.0 Preview 6 . Incluye actualizaciones para compilar ensamblajes para un inicio mejorado, optimizando las aplicaciones para el tamaño con mejoras de linker y EventPipe. También hemos lanzado nuevas imágenes de Docker para Alpine en ARM64.
Actualización de WPF y Windows Forms
El equipo de WPF ha completado la publicación de la mayor parte de la base de código de WPF en GitHub . De hecho, acaban de publicar una fuente para quince asambleas . Para cualquiera que esté familiarizado con WPF, los nombres de ensamblado deberían estar muy familiarizados.
En algunos casos, las pruebas aún están pendientes para publicarse en 3.0 GA o antes. Dicho esto, la presencia de todo este código debería permitir a la comunidad de WPF participar plenamente en la realización de cambios en WPF. Es obvio, al leer algunos de los problemas de GitHub, que la comunidad tiene su propio retraso que ha estado esperando darse cuenta. ¿Tema oscuro, tal vez?
Imágenes de estibador alpino
Las imágenes de Docker ahora están disponibles para .NET Core y ASP.NET Core en ARM64. Anteriormente solo estaban disponibles para x64.
Las siguientes imágenes se pueden usar en un Dockerfile o con docker pull , como se muestra a continuación:
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8
Mejoras en la tubería de eventos
Event Pipe ahora admite múltiples sesiones. Esto significa que puede consumir eventos con EventListener en proceso y simultáneamente tener clientes de canalización de eventos fuera de proceso.
Se agregaron nuevos contadores de perf:
- % De tiempo en GC
- Gen 0 Heap Size
- Tamaño del montón Gen 1
- Gen 2 Heap Size
- Tamaño del montón LOH
- Tasa de asignación
- Número de conjuntos cargados
- Número de subprocesos de subprocesos
- Monitor de tasa de retención de bloqueo
- Cola de elementos de trabajo de ThreadPool
- Tarifa de elementos de trabajo completados de ThreadPool
La conexión de Profiler ahora se implementa utilizando la misma infraestructura de Event Pipe.
Consulte Jugar con contadores de David Fowler para tener una idea de lo que puede hacer con el canal de eventos para realizar sus propias investigaciones de rendimiento o simplemente monitorear el estado de la aplicación.
Consulte dotnet-counters para instalar la herramienta dotnet-counters.
Optimice sus aplicaciones .NET Core con imágenes ReadyToRun
Puede mejorar el tiempo de inicio de su aplicación .NET Core compilando los ensambles de su aplicación en formato ReadyToRun (R2R). R2R es una forma de compilación anticipada (AOT).
Los archivos binarios de R2R mejoran el rendimiento de inicio al reducir la cantidad de trabajo que el JIT necesita hacer a medida que se carga su aplicación. Los archivos binarios contienen un código nativo similar al que produciría el JIT, lo que le da un poco de vacaciones cuando el rendimiento es más importante (al inicio). Los binarios de R2R son más grandes porque contienen tanto código de lenguaje intermedio (IL), que todavía se necesita para algunos escenarios, como la versión nativa del mismo código, para mejorar el inicio.
R2R es compatible con .NET Core 3.0. No se puede usar con versiones anteriores de .NET Core.
Muestra de números de rendimiento
Los siguientes son números de rendimiento recopilados utilizando una aplicación WPF de muestra . La aplicación se publicó como autónoma y no utilizó el enlazador de ensamblado (cubierto más adelante en esta publicación).
Aplicación solo para IL:
- Tiempo de inicio: 1.9 segundos
- Uso de memoria: 69,1 MB
- Tamaño de aplicación: 150 MB
Con imágenes ReadyToRun:
- Tiempo de inicio: 1.3 segundos.
- Uso de memoria: 55.7 MB
- Tamaño de aplicación: 156 MB
Imágenes de ReadyToRun, explicadas
Puede R2R compilar bibliotecas y binarios de aplicaciones. En la actualidad, las bibliotecas solo pueden compilarse R2R como parte de una aplicación, no para entregarse como un paquete NuGet. Nos gustaría recibir más comentarios sobre si ese escenario es importante.
AOT compilando ensamblajes ha estado disponible como un concepto con .NET durante mucho tiempo, volviendo a .NET Framework y NGEN . NGEN tiene un inconveniente clave, que es que la compilación debe realizarse en máquinas cliente, utilizando la herramienta NGEN. No es posible generar imágenes NGEN como parte de la construcción de su aplicación.
Ingrese a .NET Core. Viene con crossgen , que produce imágenes nativas en un formato más nuevo llamado ReadyToRun . El nombre describe su propuesta de valor principal, que es que estas imágenes nativas se pueden construir como parte de su construcción y están "listas para ejecutarse" sin ningún trabajo adicional en las máquinas cliente. Esa es una mejora importante, y también una victoria importante para el cambio climático.
En términos de compatibilidad, las imágenes de ReadyToRun son similares a los ensamblajes IL, con algunas diferencias clave.
- Los ensambles IL contienen solo el código IL . Pueden ejecutarse en cualquier tiempo de ejecución que admita el marco de destino dado para ese ensamblado. Por ejemplo, un ensamblaje
netstandard2.0 puede ejecutarse en .NET Framework 4.6+ y .NET Core 2.0+, en cualquier sistema operativo compatible (Windows, macOS, Linux) y arquitectura (Intel, ARM, 32 bits, 64 bits). - Los ensamblados R2R contienen IL y código nativo. Se compilan para una versión de tiempo de ejecución y un entorno de tiempo de ejecución (RID) mínimos específicos de .NET Core. Por ejemplo, un ensamblado
netstandard2.0 podría estar compilado R2R para .NET Core 3.0 y Linux x64. Solo se podrá usar en esa o en una configuración compatible (como .NET Core 3.1 o .NET Core 5.0, en Linux x64), porque contiene código nativo que solo se puede usar en ese entorno de tiempo de ejecución.
Instrucciones
La compilación ReadyToRun es una función de publicación solo, opcional. Hemos lanzado una versión preliminar con .NET Core 3.0 Preview 5.
Para habilitar la compilación ReadyToRun, debe:
- Establezca la propiedad
PublishReadyToRun en true . - Publicar utilizando un
RuntimeIdentifier explícito.
Nota: Cuando se compilan los ensamblados de la aplicación, el código nativo producido es específico de la plataforma y la arquitectura (es por eso que debe especificar un RuntimeIdentifier válido al publicar).
Aquí hay un ejemplo:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>
Y publique usando el siguiente comando:
dotnet publish -r win-x64 -c Release
Nota: RuntimeIdentifier también se puede configurar en el archivo del proyecto.
Nota: ReadyToRun actualmente solo es compatible con aplicaciones independientes . Se habilitará para aplicaciones dependientes del marco en una vista previa posterior.
La generación de símbolos nativos se puede habilitar configurando la propiedad PublishReadyToRunEmitSymbols en true en su proyecto. No es necesario generar símbolos nativos para fines de depuración. Estos símbolos solo son útiles para la creación de perfiles.
Actualmente, el SDK admite una forma de excluir ciertos ensamblados de ser compilados en imágenes ReadyToRun. Esto podría ser útil para los casos en que ciertos ensambles realmente no necesitan ser optimizados para el rendimiento. Esto puede ayudar a reducir el tamaño de la aplicación. También podría ser una solución útil para los casos en los que el compilador ReadyToRun no puede compilar un determinado ensamblado. La exclusión se realiza mediante el grupo de elementos PublishReadyToRunExclude. Ejemplo:
<ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup>
Compilaciones multiplataforma / arquitectura
El compilador ReadyToRun actualmente no admite la orientación cruzada. Necesita compilar en un objetivo dado. Por ejemplo, si desea imágenes R2R para Windows x64, debe ejecutar el comando de publicación en ese entorno.
Excepciones a esto:
- Windows x64 se puede usar para compilar imágenes de Windows ARM32, ARM64 y x86.
- Windows x86 se puede usar para compilar imágenes de Windows ARM32.
- Linux x64 se puede usar para compilar imágenes Linux ARM32 y ARM64.
Enlace de ensamblaje
El SDK de .NET core 3.0 viene con una herramienta que puede reducir el tamaño de las aplicaciones mediante el análisis de IL y el recorte de ensamblajes no utilizados.
Con .NET Core, siempre ha sido posible publicar aplicaciones independientes que incluyen todo lo necesario para ejecutar su código, sin que sea necesario instalar .NET en el destino de implementación. En algunos casos, la aplicación solo requiere un pequeño subconjunto del marco para funcionar y podría hacerse mucho más pequeña al incluir solo las bibliotecas utilizadas.
Usamos el enlazador IL para escanear el IL de su aplicación para detectar qué código se requiere realmente y luego recortar las bibliotecas de marco no utilizadas. Esto puede reducir significativamente el tamaño de algunas aplicaciones. Por lo general, las aplicaciones de consola pequeñas similares a herramientas se benefician más, ya que tienden a usar subconjuntos bastante pequeños del marco y generalmente son más susceptibles de recorte.
Para usar esta herramienta, configure PublishTrimmed=true en su proyecto y publique una aplicación autónoma:
dotnet publish -r <rid> -c Release
La salida de publicación incluirá un subconjunto de las bibliotecas de framework, dependiendo de lo que llame el código de la aplicación. Para una aplicación helloworld, el enlazador reduce el tamaño de ~ 68MB a ~ 28MB.
Las aplicaciones o marcos (incluidos ASP.NET Core y WPF) que usan reflexión o características dinámicas relacionadas a menudo se rompen cuando se recortan, porque el vinculador no conoce este comportamiento dinámico y generalmente no puede determinar qué tipos de marcos serán necesarios para la reflexión en tiempo de ejecución. Para recortar tales aplicaciones, debe informarle al vinculador sobre cualquier tipo necesario por reflejo en su código y en cualquier paquete o marco del que dependa. Asegúrese de probar sus aplicaciones después de recortar.
Para obtener más información sobre IL Linker, consulte la documentación o visite el repositorio mono / linker .
Nota: En versiones anteriores de .NET Core, ILLink.Tasks se incluía como un paquete NuGet externo y proporcionaba la misma funcionalidad. Ya no es compatible: actualice al SDK 3.0 más reciente y pruebe la nueva experiencia.
Usando el enlazador y ReadToRun juntos
El enlazador y el compilador ReadyToRun se pueden usar para la misma aplicación. En general, el vinculador hace que su aplicación sea más pequeña, y luego el compilador listo para ejecutar la hará un poco más grande nuevamente, pero con una ganancia de rendimiento significativa. Vale la pena probarlo en varias configuraciones para comprender el impacto de cada opción.
Nota: dotnet / sdk # 3257 evita que el enlazador y ReadyToRun se usen juntos para las aplicaciones WPF y Windows Forms. Estamos trabajando para solucionarlo como parte de la versión .NET Core 3.0.
Muestra de alojamiento nativo
El equipo publicó recientemente una muestra de alojamiento nativo . Demuestra un enfoque de mejores prácticas para alojar .NET Core en una aplicación nativa.
Como parte de .NET Core 3.0, ahora exponemos la funcionalidad general a los hosts nativos de .NET Core que anteriormente solo estaban disponibles para las aplicaciones administradas de .NET Core a través de los hosts .NET Core provistos oficialmente. La funcionalidad está relacionada principalmente con la carga del ensamblaje. Esta funcionalidad debería facilitar la producción de hosts nativos que puedan aprovechar el conjunto completo de características de .NET Core.
Soporte HTTP / 2 en HttpClient
HTTP / 2 es una revisión importante del protocolo HTTP. Algunas de las características notables de HTTP / 2 son soporte para compresión de encabezado y flujos completamente multiplexados a través de la misma conexión. Si bien HTTP / 2 conserva la semántica de HTTP (encabezados HTTP, métodos, etc.) es un cambio de HTTP / 1.x en la forma en que los datos se enmarcan y se envían a través del cable.
HttpClient ahora agrega soporte para realizar solicitudes HTTP / 2. Si bien el valor predeterminado sigue siendo HTTP / 1.1, puede optar por usar HTTP / 2 configurando la versión en su mensaje de solicitud HTTP.
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };
Alternativamente, puede enviar por defecto las solicitudes HTTP / 2 configurando la propiedad DefaultRequestVersion en HttpClient .
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) };
Como consecuencia de este cambio en el encuadre, los servidores y los clientes deben negociar la versión de protocolo utilizada. Application-Layer Protocol Negotiation (ALPN) es una extensión TLS que permite al servidor y al cliente negociar la versión del protocolo utilizada como parte de su protocolo de enlace TLS. Si bien es posible tener conocimiento previo entre el servidor y el cliente en el protocolo, la mayoría de los servidores solo admiten ALPN como la única forma de establecer una conexión HTTP / 2. Como tal, HTTP / 2 es negociado por HttpClient solo en una conexión TLS.
En escenarios de desarrollo cuando el servidor y el cliente tienen un conocimiento previo de que ambos hablarán HTTP / 2 sin cifrar, puede establecer una conexión HTTP / 2 sobre texto sin cifrar configurando un AppContext o una variable de entorno ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
Clausura
Por favor, pruebe las nuevas funciones. Presente los problemas de los errores o cualquier experiencia desafiante que encuentre. Queremos los comentarios! También puede presentar solicitudes de funciones, pero es probable que tengan que esperar para implementarse hasta la próxima versión en este momento.
Ahora nos estamos acercando a las características completas para .NET Core 3.0, y ahora estamos haciendo la transición del enfoque del equipo a la calidad del lanzamiento. Tenemos algunos meses de corrección de errores y trabajo de rendimiento por delante. Agradeceremos sus comentarios mientras trabajamos en ese proceso también.
En ese sentido, pronto cambiaremos las ramas master en los repositorios de .NET Core a la próxima versión principal, probablemente en o poco después de la versión Preview 7 (julio).
Gracias por probar las vistas previas de .NET Core 3.0. Agradecemos tu ayuda. En este punto, estamos enfocados en obtener una versión final en tus manos.
Richard LanderPM, equipo .NET