Novedades del SDK y las herramientas para .NET 11

En este artículo se describen las nuevas características y mejoras del SDK de .NET para .NET 11. Se actualizó por última vez para la versión preliminar 4.

Tamaño del SDK

El tamaño del instalador del SDK de .NET en Linux y macOS se ha reducido mediante la desduplicación de ensamblados mediante vínculos simbólicos. Los archivos duplicados .dll y .exe se identifican mediante el hash de contenido y se reemplazan por vínculos simbólicos que apuntan a una sola copia. Esto afecta a las bolas de alquiltrán, .pkg, .deb, y .rpm a los instaladores.

El análisis encontró que 35% del directorio del SDK consta de archivos duplicados. En Linux x64, es decir, 816 archivos con un total de 140 MB en disco (53 MB comprimidos). Al reemplazar duplicados por vínculos simbólicos, el archivo x64 de Linux disminuye significativamente en tamaño:

Plataforma Artefacto del SDK Tamaño de .NET 10 (MB) tamaño de la versión preliminar 2 de .NET 11 (MB) Reducción
linux-x64 tarball 230 189 17.8%
linux-x64 deb 164 122 25.6%
linux-x64 revoluciones por minuto 165 122 26.0%
linux-x64 contenedores Varía Varía 8–17%

El SDK se recorta aún más porque se omite crossgen para los ensamblados que solo existen en DotnetTools/. Los ensamblados que también existen fuera de DotnetTools/ se siguen precompilando con Crossgen: se benefician de un inicio más rápido y luego se elimina el duplicado; pero los ensamblados exclusivos de DotnetTools/ se dejan solo como IL. En una compilación linux-x64, esto reduce el archivo tar del SDK en 23,6 MB adicionales.

La deduplicación de Windows está prevista para una futura previsualización.

Análisis de código y advertencias

Mejoras del analizador de código

CA1873: Ruido reducido y mensajes mejorados

Se realizaron dos mejoras en CA1873 (Evitar el registro potencialmente costoso):

Reducción de falsos positivos: Los accesos a la propiedad, GetType(), GetHashCode(), y GetTimestamp() las llamadas ya no se marcan. Los diagnósticos ahora solo se aplican por defecto al registro a nivel de información y inferiores, ya que las rutas de advertencia, error y código crítico rara vez son rutas activas.

Motivos específicos de los mensajes de diagnóstico: El mensaje de diagnóstico ahora incluye por qué se marcó un argumento, lo que le ayuda a priorizar qué advertencias abordar:

// Before
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled

// After
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled (method invocation)

Las nueve razones específicas son:

  • Invocación de método
  • Creación de objetos
  • creación de matriz
  • Conversión en boxeo
  • Interpolación de cadenas
  • Expresión de colección
  • Creación de objetos anónimos
  • Espera la expresión
  • Con expresión

Correcciones de errores del analizador

Analyzer Corregir
CA1515 Falso positivo corregido cuando hay miembros de extensión C# presentes
CA1034 Falso positivo corregido cuando hay miembros de extensión C# presentes
CA1859 Se ha corregido un control incorrecto de las implementaciones de interfaz predeterminadas.

AnalysisLevel corregido para .NET 11

Los proyectos con AnalysisLevel=latest estaban usando incorrectamente reglas de analizador .NET 9 en lugar de las reglas de .NET 11 esperadas. Este problema ya está solucionado.

Nuevas advertencias del SDK

NETSDK1235: .nuspec personalizado con PackAsTool

Se genera una nueva advertencia cuando un proyecto establece PackAsTool=true y especifica una propiedad personalizada NuspecFile . Los paquetes de herramientas requieren convenciones de diseño e identificador específicas que normalmente infringen los archivos personalizados .nuspec :

warning NETSDK1235: .NET Tools do not support using a custom .nuspec file, but the nuspec file 'custom.nuspec' was provided. Remove the NuspecFile property from this project to enable packing it as a .NET Tool.

La operación de la carga sigue adelante con una advertencia para evitar romper los proyectos existentes.

Productividad del desarrollador y el flujo de trabajo de la CLI

Soporte de CLI para filtros de soluciones

dotnet sln ahora puede crear y editar filtros de solución (.slnf) directamente desde la CLI. Los filtros de solución permiten que los repositorios de gran tamaño se carguen o compilen un subconjunto de proyectos sin cambiar la solución principal. Las operaciones admitidas son un reflejo de los comandos existentes dotnet sln :

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet sln MyApp.slnf list
dotnet sln MyApp.slnf remove src/Lib/Lib.csproj

Aplicaciones basadas en archivos divididas entre archivos

Las aplicaciones basadas en archivos ahora admiten una #:include directiva, por lo que puede mover asistentes compartidos a archivos independientes sin renunciar al flujo de trabajo basado en archivos:

#:include helpers.cs
#:include models/customer.cs

Console.WriteLine(Helpers.FormatOutput(new Customer()));

Pasar variables de entorno con dotnet run

dotnet run -e KEY=VALUE pasa variables de entorno a la aplicación iniciada desde la línea de comandos, sin necesidad de exportar el estado del shell ni editar perfiles de inicio:

dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debug

Las variables de entorno pasadas de esta manera están disponibles para la lógica de MSBuild como RuntimeEnvironmentVariable elementos.

mejoras de dotnet Watch

.NET 11 incorpora varias dotnet watch mejoras para ciclos largos de desarrollo local:

  • Aspire integración:dotnet watch ahora es posible integrarse con Aspire hosts de aplicaciones, lo que permite flujos de trabajo con recarga en caliente en todo el Aspire modelo de aplicación.
  • Recuperación de bloques: Cuando la app se bloquea, dotnet watch se reinicia automáticamente al siguiente cambio relevante en el archivo.
  • Soporte de escritorio de Windows: El manejo de Ctrl+C ha mejorado para aplicaciones de escritorio de Windows como Windows Forms y WPF.

.NET 11 también agrega selección de dispositivos para proyectos MAUI y móviles. Después de seleccionar un marco de destino, dotnet watch llama al ComputeAvailableDevices destino de MSBuild, selecciona automáticamente cuando hay un único dispositivo y muestra un selector interactivo con la búsqueda cuando hay varios. El dispositivo seleccionado se transmite a dotnet build y al subproceso dotnet run iniciado, incluida una nueva restauración cuando el dispositivo requiere un RuntimeIdentifier que no está presente en la restauración original.

Para seleccionar previamente un dispositivo desde la línea de comandos, use:

dotnet watch --device <device-id>

Se han corregido los siguientes problemas de larga duración dotnet watch :

  • El mensaje de selección del marco ya no aparece bloqueado debido a dos lectores que llaman a Console.ReadKey().
  • Ctrl+C y Ctrl+R ya no muestran un WebSocketException o ObjectDisposedException espurio cuando el transporte WebSocket se cierra.
  • Recarga activa ya no provoca interbloqueos en iOS cuando se instala UIKitSynchronizationContext antes de que se ejecute el hook de inicio.

Note

dotnet watch requiere <MtouchLink>None</MtouchLink> en el archivo .csproj para proyectos para el simulador de iOS. Consulte dotnet/macios #25295.

Finalizaciones de conchas de pescado

Anteriormente, el proveedor de fish shell emitía un comando de una sola línea que delegaba cada completado en una llamada dinámica dotnet complete. El script generado ahora recorre la línea de comandos con token, emite finalizaciones estáticas para subcomandos, opciones y argumentos posicionales, y vuelve a llamadas dinámicas solo cuando sea necesario. Esto coincide con el comportamiento de los proveedores de Bash, Zsh y PowerShell.

La referencia de dotnet vuelve al directorio actual

dotnet reference add y dotnet reference remove ahora recurren al directorio actual cuando no se proporciona ningún --project, en consonancia con el comportamiento tradicional de dotnet reference list:

cd ClassLib2
dotnet reference add ../ClassLib1/ClassLib1.csproj   # now works without --project
dotnet reference remove ../ClassLib1/ClassLib1.csproj

Anteriormente, estos comandos fallaban con Could not find project or directory '' cuando se ejecutaban desde un directorio que contenía un archivo de proyecto.

Aviso de configuración de inicio movido a stderr

El mensaje informativo "Usando la configuración de inicio de..." ahora se escribe en stderr en lugar de stdout. Los scripts que capturan la salida estándar de dotnet run ya no necesitan quitar esta línea.

Otras mejoras de la CLI

  • dotnet format ahora acepta --framework para proyectos multiobjetivo.
  • dotnet test en el modo Microsoft Testing Platform (MTP) ahora soporta --artifacts-path.
  • dotnet tool exec y dnx ya no solicitan una aprobación adicional al ejecutar herramientas.
  • dotnet nuget <subcommand> --help ahora reenvía correctamente a la salida de ayuda de la CLI de NuGet en lugar de revertir a la ayuda genérica.
  • dotnet publish ya no elimina DLL nativas en ejecuciones posteriores de la publicación de archivo único.

Activos web y telemetría

Grupos de recursos para recursos web estáticos

El SDK de activos web estáticos agrega compatibilidad con grupos de recursos, una manera de declarar grupos de recursos relacionados que comparten metadatos de publicación, huella digital y punto de conexión. La tarea relacionada DefineStaticWebAssetEndpoints incorpora el parámetro AdditionalEndpointDefinitions, y el comparador de patrones glob expone el segmento base capturado ** para que se puedan definir declarativamente puntos de acceso adicionales (por ejemplo, rutas de documento predeterminado como / para **/index.html).

Esta es la infraestructura para los autores de componentes de ASP.NET Core y los autores de extensiones del SDK. La mayoría de los desarrolladores de aplicaciones ven el resultado indirectamente a medida que los paquetes de componentes de Razor y Blazor envían metadatos de activos estáticos más limpios.

OpenTelemetry reemplaza Application Insights para la telemetría de la CLI

La CLI de dotnet ahora usa OpenTelemetry (OTel) con exportadores de Azure Monitor y OTLP para su telemetría opcional, en sustitución de la dependencia anterior Microsoft.ApplicationInsights. El comportamiento visible para el usuario permanece inalterado: se recopila la misma telemetría, con la misma opción de exclusión mediante DOTNET_CLI_TELEMETRY_OPTOUT. La motivación es hacer que la CLI NativeAOT sea fácil de usar.

Arquitectura de la CLI

Punto de entrada de NativeAOT para la CLI de dotnet

Para permitir un arranque casi instantáneo en las invocaciones habituales de la CLI, .NET 11 sienta las bases de un host de CLI compilado con NativeAOT dotnet. El trabajo presenta tres capas:

  • dn.exe — un host de NativeAOT que resuelve DOTNET_ROOT y hostfxr y convierte los argumentos para pasarlos a una biblioteca compartida de NativeAOT. Esto está destinado a pruebas internas del repositorio SDK, no al uso en producción.
  • dotnet-aot.dll : una biblioteca compartida de NativeAOT que controla comandos simples, como --version y --info directamente, y recurre a la CLI administrada completa para todo lo demás.
  • dotnet.dll — la CLI gestionada existente, con #if CLI_AOT condicionales para compilar los mismos archivos de origen en ambas rutas.

El objetivo es el inicio casi instantáneo para las invocaciones más comunes de la CLI, a la vez que se conserva la funcionalidad completa para el resto. El nuevo punto de entrada aún no es el binario predeterminado dotnet .

ReadyToRun parcial para herramientas de capas superiores

Una nueva propiedad de MSBuild permite que las herramientas de nivel superior (como dotnet/macios y dotnet/maui) especifiquen una lista de ensamblados para compilarlos parcialmente con R2R y excluirlos de la imagen compuesta. El escenario motivador es precompilar el código XAML generado en compilaciones de depuración para acelerar F5 sin pagar el costo total de crossgen para el resto de la aplicación. Los desarrolladores de aplicaciones no establecen esta propiedad directamente, es un enlace que usan las cargas de trabajo móviles en sus destinos.

Consulte también

  • Last updated on