La semana pasada, se lanzó .NET Core 3.0 (Vista previa 6) . Incluye actualizaciones de compilación de ensamblaje para mejorar el lanzamiento, mejorar la optimización del tamaño de las aplicaciones con mejoras en el enlazador y EventPipe. También lanzamos nuevas imágenes de Docker para Alpine en ARM64.
Actualizaciones de formularios WPF y Windows
El equipo de WPF ha completado el proceso de publicación de la mayor parte del código de WPF en GitHub . De hecho, acaban de publicar el código fuente de quince compilaciones . Para aquellos familiarizados con WPF, los nombres de ensamblado deberían estar muy familiarizados.
En algunos casos, las pruebas todavía están en el trabajo atrasado y deben publicarse en 3.0 GA o antes. Sin embargo, 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. Después de leer algunos problemas con GitHub, resulta obvio que la comunidad tiene su propia cartera de productos nuevos que desea implementar. ¿Qué opinas del tema oscuro?
Alpine Docker Images
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 el Dockerfile , o con el 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 de canalización de eventos
Event Pipe ahora es compatible con la multisectorialidad.
Se agregaron nuevos contadores de rendimiento:
- % 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
Las uniones de Profiler ahora se implementan utilizando la misma infraestructura de Event Pipe.
Lea el juego de conteo de David Fowler para tener una idea de lo que puede hacer con el canal de eventos para hacer su propia investigación de rendimiento o simplemente realizar un seguimiento del estado de la aplicación.
Lea dotnet-counters para instalar la herramienta dotnet-counters.
Optimice sus aplicaciones .NET Core con imágenes ReadyToRun
Puede mejorar el tiempo de inicio de una aplicación .NET Core compilando compilaciones de aplicaciones en formato ReadyToRun (R2R). R2R es una forma de compilación líder (AOT).
Los binarios de R2R mejoran el rendimiento de inicio al reducir la cantidad de trabajo que JIT necesita hacer cuando se carga la aplicación. Los archivos binarios contienen código de máquina similar al generado por el JIT, que le da un poco de descanso cuando el rendimiento es más importante (en el inicio). Los archivos binarios en el formato R2R son más grandes porque contienen código de lenguaje intermedio (IL), que todavía es necesario para algunos escenarios, y una versión de máquina 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.
Cifras de rendimiento de muestra
Las siguientes son figuras que muestran el rendimiento de muestras de aplicaciones WPF . La aplicación se publicó como independiente y no utilizó el enlazador de ensamblado (que se trata más adelante en este artículo).
Aplicación solo para IL:
- Tiempo de arranque: 1.9 segundos
- Uso de memoria: 69,1 MB
- Tamaño de aplicación: 150 MB
Con imágenes ReadyToRun:
- Tiempo de arranque: 1.3 segundos.
- Uso de memoria: 55.7 MB
- Tamaño de aplicación: 156 MB
Lea más sobre las imágenes de ReadyToRun
Puede compilar R2R tanto bibliotecas como archivos binarios de aplicaciones. Actualmente, las bibliotecas solo pueden compilarse en R2R como parte de la aplicación, y no para entregarse como un paquete NuGet. Nos gustaría recibir más comentarios sobre si este escenario es importante.
La compilación de ensamblajes AOT ha estado disponible durante mucho tiempo como un concepto para .NET, volviendo a .NET Framework y NGEN . Una desventaja clave de NGEN 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.
Ahora .NET Core. Viene con crossgen , que produce imágenes de máquina en el nuevo formato ReadyToRun . El nombre describe su valor central, a saber, que estas imágenes de máquina se pueden crear como parte de su ensamblaje y están "listas para ejecutarse" sin ningún trabajo adicional en las máquinas cliente. Esta es una mejora importante, así como una victoria importante en la lucha contra el cambio climático.
En términos de compatibilidad, las imágenes ReadyToRun son similares a los ensamblajes IL con algunas diferencias clave.
- Los ensambles IL contienen solo código IL . Pueden funcionar en cualquier entorno de tiempo de ejecución que admita la infraestructura de destino especificada para este ensamblado. Por ejemplo, la compilación
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 mínima específica del tiempo de ejecución de .NET Core y el entorno de tiempo de ejecución (RID). por ejemplo, la compilación
netstandard2.0 puede compilarse con R2R para .NET Core 3.0 y Linux x64. Solo se usará en esta o en una configuración compatible (por ejemplo, .NET Core 3.1 o .NET Core 5.0 en Linux x64), porque contiene código nativo que solo se puede usar en este entorno de tiempo de ejecución.
Instrucciones
La compilación ReadyToRun está disponible solo para publicación. La versión de vista previa se lanzó en .NET Core 3.0 (Vista previa 5).
Para habilitar la compilación ReadyToRun, debe:
- Establezca el valor de la propiedad
PublishReadyToRun en true . - Publica usando el
RuntimeIdentifier exacto.
Nota Cuando se compilan las compilaciones de la aplicación, el código nativo generado depende de la plataforma y la arquitectura (por lo tanto, al publicar, debe especificar un RuntimeIdentifier válido).
Aquí hay un ejemplo:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>
Y publicando usando el siguiente comando:
dotnet publish -r win-x64 -c Release
Nota: RuntimeIdentifier se puede establecer en el archivo del proyecto.
Nota: ReadyToRun actualmente solo es compatible con aplicaciones independientes . Se agregará para aplicaciones dependientes del marco en un anuncio posterior.
La generación de caracteres de la máquina se puede habilitar estableciendo la propiedad PublishReadyToRunEmitSymbols en true . No es necesario crear caracteres de máquina con fines de depuración. Estos caracteres solo son útiles para la creación de perfiles.
Actualmente, el SDK admite una forma de excluir ciertos ensamblajes de la compilación en imágenes ReadyToRun. Esto puede ser útil en casos donde los ensambles no necesitan ser optimizados para mejorar el rendimiento. Excluir ensamblados en este caso puede ayudar a reducir el tamaño de la aplicación. En el caso de que el compilador ReadyToRun no pueda compilar un ensamblaje específico, la solución también puede ser eliminarlo.
Se lanza una excepción usando el grupo de elementos PublishReadyToRunExclude:
<ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup>
Compilación multiplataforma / arquitectónica
El compilador ReadyToRun aún no admite la orientación cruzada. Necesita compilar para un objetivo determinado. Por ejemplo, si necesita imágenes R2R para Windows x64, debe ejecutar el comando de publicación en este entorno.
Excepciones:
- 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 de Linux ARM32 y ARM64.
Diseño de montaje
El SDK NET core 3.0 viene con una herramienta que puede reducir el tamaño de la aplicación al analizar IL y eliminar las compilaciones no utilizadas.
Con .NET Core, siempre puede publicar aplicaciones independientes que incluyen todo lo que necesita para ejecutar su código, sin tener que instalar .NET en el destino de implementación. En algunos casos, la aplicación requiere solo un pequeño subconjunto del marco, y podría hacerse mucho más pequeño al incluir solo las bibliotecas utilizadas.
Usamos el generador de IL para escanear el IL de su aplicación para determinar qué código se requiere realmente y luego excluimos las bibliotecas de marco no utilizadas. Esto puede reducir significativamente el tamaño de algunas aplicaciones. Como regla general, las aplicaciones de consola pequeñas, como las herramientas, obtienen el mayor beneficio, ya que a menudo usan pequeños subconjuntos del marco y generalmente se prestan bien para el recorte.
Para usar esta herramienta, configure PublishTrimmed=true en su proyecto y publique la aplicación independiente:
dotnet publish -r <rid> -c Release
El resultado de la publicación incluirá un subconjunto de las bibliotecas de infraestructura, según el código de aplicación que se invoque. Para la aplicación helloworld, el enlazador reduce el tamaño de ~ 68 MB a ~ 28 MB.
Las aplicaciones o marcos (incluidos ASP.NET Core y WPF) que usan reflexión o funciones dinámicas relacionadas a menudo se rompen al recortar porque el vinculador no es consciente de 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 informar al vinculador sobre cualquier tipo necesario para la reflexión en su código y en cualquier paquete o entorno 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 envió como un paquete NuGet externo y proporcionó la mayor parte de la misma funcionalidad. Ya no es compatible: actualice a la última versión 3.0 SDK.
Linker y ReadToRun Linker Sharing
Linker Linker y ReadyToRun Linker 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 un aumento significativo en el rendimiento. Vale la pena probar varias configuraciones para comprender el efecto de cada opción.
Nota: dotnet / sdk # 3257 impide el uso compartido del enlazador y ReadyToRun para aplicaciones WPF y Windows Forms. Estamos trabajando para solucionar esto como parte de la versión .NET Core 3.0.
Muestra de alojamiento nativo
Recientemente se publicó una muestra de alojamiento nativo . Demuestra el mejor enfoque para alojar .NET Core en una aplicación nativa.
Dentro del marco de .NET Core 3.0, ahora ofrecemos una funcionalidad común a nuestros propios servicios de alojamiento .NET Core, que anteriormente solo estaban disponibles para aplicaciones administradas de .NET Core a través de servicios de alojamiento .NET Core provistos oficialmente. La funcionalidad se asocia principalmente con la carga del ensamblaje. Esta funcionalidad debería facilitar la creación de sus propios servicios de alojamiento que pueden utilizar la gama completa de características de .NET Core.
Soporte HTTP / 2 en HttpClient
HTTP / 2 es la versión principal del protocolo HTTP. Algunas de las características notables de HTTP / 2 son el soporte de compresión de encabezado y las secuencias totalmente multiplexadas en una sola conexión. Aunque HTTP / 2 conserva la semántica de HTTP (encabezados HTTP, métodos, etc.), difiere de HTTP / 1.x en cómo se envían los datos.
HttpClient ahora admite solicitudes HTTP / 2. Por defecto, todo sigue siendo HTTP / 1.1, pero puede optar por no utilizar HTTP / 2 instalando la versión utilizando una solicitud HTTP.
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };
Alternativamente, puede enviar solicitudes HTTP / 2 de forma predeterminada configurando DefaultRequestVersion a HttpClient .
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) };
Como resultado de este cambio, los servidores y los clientes deben acordar la versión de protocolo utilizada. ALPN (Application-Layer Protocol Negotiation) es una extensión TLS que permite al servidor y al cliente negociar la versión del protocolo utilizada como parte de su interacción. Sin embargo, tenga en cuenta que la mayoría de los servidores solo admiten ALPN como la única forma de establecer una conexión HTTP / 2. Por lo tanto, HTTP / 2 es negociado por HttpClient solo a través de la conexión TLS.
En escenarios de desarrollo, cuando el servidor y el cliente saben a priori que ambos hablarán HTTP / 2 sin cifrado, puede establecer una conexión HTTP / 2 a través de texto sin AppContext configurando el AppContext o la variable de entorno. ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
Finalización
Estaremos muy contentos si prueba nuevas funciones. Por favor, informe de los problemas o errores que encuentre. También puede enviar solicitudes de nuevas funciones, pero su implementación tendrá que esperar hasta la próxima versión.
Ahora estamos muy cerca de completar el trabajo en el componente .NET Core 3.0 y ahora estamos cambiando la atención del equipo para mejorar la calidad de la versión. Tenemos meses de anticipación para corregir errores y mejorar el rendimiento.
Por cierto, para la próxima actualización importante, cambiaremos las ramas master en los repositorios de .NET Core. Lo más probable es que esto suceda inmediatamente después de la Vista previa 7 en julio.
Gracias por probar .NET Core 3.0. Agradecemos tu ayuda. Por el momento, estamos enfocados en hacer que la versión final sea la más interesante y de alta calidad para usted.