Novedades del SDK y las herramientas para .NET 9

En este artículo se describen las nuevas características del SDK de .NET y las herramientas para .NET 9.

Pruebas unitarias

En esta sección se describen las actualizaciones de las pruebas unitarias en .NET 9: ejecución de pruebas en paralelo y salida de prueba del registrador de terminal.

Ejecución de pruebas en paralelo

En .NET 9, dotnet test está totalmente integrado con MSBuild. Dado que MSBuild admite la compilación en paralelo, puede ejecutar pruebas para el mismo proyecto en distintas plataformas de destino en paralelo. De forma predeterminada, MSBuild limita el número de procesos paralelos al número de procesadores del equipo. También puede establecer su propio límite mediante el modificador -maxcpucount . Si desea excluirse del paralelismo, configure la propiedad MSBuild en false.

Pantalla de prueba del registrador de terminal

Los informes de resultados de pruebas para dotnet test ahora se admiten directamente en el registrador de terminales de MSBuild. Obtendrá informes de pruebas más completos mientras se ejecutan las pruebas (muestra el nombre de la prueba en ejecución) y una vez completadas las pruebas (los errores de prueba se representan de una manera mejor).

Para obtener más información sobre Terminal Logger, consulte opciones de compilación de .NET.

Avance de la herramienta .NET

Las herramientas de .NET son aplicaciones dependientes del marco de trabajo que se pueden instalar de forma global o local y, después, se ejecutan mediante el SDK de .NET y los entornos de ejecución de .NET instalados. Estas herramientas, como todas las aplicaciones de .NET, tienen como destino una versión principal específica de .NET. De forma predeterminada, las aplicaciones no se ejecutan en versiones más recientes de .NET. Los autores de herramientas han podido optar por ejecutar sus herramientas en versiones más recientes del entorno de ejecución de .NET estableciendo la RollForward propiedad MSBuild. Sin embargo, no todas las herramientas lo hacen.

Una nueva opción para dotnet tool install permite a los usuarios decidir cómo se deben ejecutar las herramientas de .NET. Al instalar una herramienta a través dotnet tool installde , o al ejecutar la herramienta a través dotnet tool run <toolname>de , puede especificar una nueva marca denominada --allow-roll-forward. Esta opción configura la herramienta con el modo de avance progresivo Major. Este modo permite que la herramienta se ejecute en una versión principal más reciente de .NET si la versión de .NET coincidente no está disponible. Esta característica ayuda a los primeros usuarios a usar herramientas de .NET sin que los autores de herramientas tengan que cambiar ningún código.

Registrador de terminales

El registrador de terminal ahora está habilitado de forma predeterminada y también ha mejorado la facilidad de uso.

Habilitado de forma predeterminada

A partir de .NET 9, la experiencia predeterminada para todos los comandos de la CLI de .NET que usan MSBuild es el registrador de terminales, la experiencia de registro mejorada que se publicó en .NET 8. Esta nueva salida usa las funcionalidades de los terminales modernos para proporcionar funcionalidades como:

• Vínculos en los que se pueden hacer clic
• Temporizadores de duración para tareas de MSBuild
• Codificación de colores de mensajes de advertencia y error

La salida es más condensada y utilizable que el registrador de consola de MSBuild existente.

El nuevo registrador intenta detectar automáticamente si se puede usar, pero también puede controlar manualmente si se usa el registrador de terminales. Especifique la --tl:off opción de línea de comandos para deshabilitar el registrador de terminales para un comando específico. O bien, para deshabilitar el registrador de terminales de forma más amplia, establezca la MSBUILDTERMINALLOGGER variable de entorno en off.

El conjunto de comandos que usa el registrador de terminales de forma predeterminada es:

• build
• clean
• msbuild
• pack
• publish
• restore
• test

Usability

El registrador de terminal ahora resume el recuento total de errores y advertencias al final de una compilación. También muestra errores que contienen nuevas líneas. (Para obtener más información sobre Terminal Logger, vea opciones de 'dotnet build', específicamente la --tl opción.)

Tenga en cuenta el siguiente archivo de proyecto que emite una advertencia cuando se compila el proyecto:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <Target Name="Error" BeforeTargets="Build">
    <Warning Code="ECLIPSE001" Text="Black Hole Sun, won't you come
  And wash away the rain
    Black Hole Sun, won't you come
      won't you come" />
  </Target>
</Project>

Cuando se ejecuta dotnet build -tl en el SDK de .NET 8, la salida es como se muestra después de este párrafo. Es difícil de leer ya que cada línea de la advertencia multilínea aparece como una línea independiente con un prefijo de mensaje de error completo en la salida. Además, el resumen final de la compilación indica que había advertencias, pero no cuántas había. La información que falta puede dificultar la determinación de si una compilación determinada es mejor o peor que las compilaciones anteriores.

$ dotnet build -tl
MSBuild version 17.8.5+b5265ef37 for .NET
Restore complete (0.5s)
  multiline-error-example succeeded with warnings (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001: Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:   And wash away the rain
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:     Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:       won't you come
Build succeeded with warnings in 0.9s

Al compilar el mismo proyecto mediante el SDK de .NET 9, la salida es la siguiente:

> dotnet build -tl
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  multiline-error-example succeeded with 3 warning(s) (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:
      Black Hole Sun, won't you come
        And wash away the rain
          Black Hole Sun, won't you come
            won't you come
Build succeeded with 3 warning(s) in 0.8s

Las líneas de mensaje de la advertencia ya no tienen la información repetida del proyecto y la ubicación que sobrecargan la pantalla. Además, el resumen de compilación muestra cuántas advertencias (y errores, si hay alguna) se generaron durante la compilación.

Si tiene comentarios sobre el registrador de terminales, puede proporcionarlo en el repositorio de MSBuild.

Resolución de dependencias de NuGet más rápida para repositorios grandes

El solucionador de dependencias de NuGet se ha revisado para mejorar el rendimiento y la escalabilidad de todos los <PackageReference> proyectos. Habilitado de forma predeterminada, el nuevo algoritmo acelera las operaciones de restauración sin poner en peligro la funcionalidad, cumpliendo estrictamente las reglas de resolución de dependencias principales.

Si encuentra algún problema, como errores de restauración o versiones inesperadas del paquete, puede revertir a la resolución heredada.

Analizadores de scripts de MSBuild ("BuildChecks")

.NET 9 presenta una característica que ayuda a protegerse frente a defectos y regresiones en los scripts de compilación. Para ejecutar las comprobaciones de compilación, agregue la /check marca a cualquier comando que invoque MSBuild. Por ejemplo, dotnet build myapp.sln /check compila la myapp solución y ejecuta todas las comprobaciones de compilación configuradas.

El SDK de .NET 9 incluye un pequeño número de comprobaciones iniciales, por ejemplo, BC0101 y BC0102. Para obtener una lista completa, consulte Códigos buildCheck.

Cuando se detecta un problema, se genera un diagnóstico en la salida de compilación del proyecto que contiene el problema.

Para obtener más información, consulte la documentación de diseño.

Incompatibilidad del analizador

Muchos usuarios instalan el SDK de .NET y Visual Studio con diferentes cadencias. Aunque esta flexibilidad es deseable, puede provocar problemas para las herramientas que necesitan interoperabilidad entre los dos entornos. Un ejemplo de este tipo de herramientas es Roslyn Analyzers. Los autores del analizador tienen que codificar para versiones específicas de Roslyn, pero las versiones que están disponibles y que se usan en una compilación determinada a veces no están claras.

Este tipo de desajuste de versiones entre el SDK de .NET y MSBuild se conoce como SDK desajustado. Cuando se encuentra en este estado, es posible que vea errores como este:

CSC: advertencia CS9057: ensamblado del analizador '..\dotnet\sdk\8.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators.dll" hace referencia a la versión "4.9.0.0" del compilador, que es más reciente que la versión actualmente en ejecución "4.8.0.0".

.NET 9 puede detectar y ajustar automáticamente este escenario de problema. La lógica de MSBuild del SDK inserta la versión de MSBuild con la que se incluye y esa información se puede usar para detectar cuándo se ejecuta el SDK en un entorno con una versión diferente. Cuando esto sucede, el SDK inserta una descarga implícita de un paquete de soporte técnico denominado Microsoft.Net.Sdk.Compilers.Toolset que garantiza una experiencia de analizador coherente.

Conjuntos de cargas de trabajo

Los conjuntos de cargas de trabajo son una característica del SDK diseñada para proporcionar a los usuarios más control sobre las cargas de trabajo que instalan y la cadencia del cambio de esas cargas de trabajo. En versiones anteriores, las cargas de trabajo se actualizaron periódicamente a medida que se publicaron nuevas versiones de cargas de trabajo individuales en las fuentes de NuGet configuradas. Ahora, todas las cargas de trabajo permanecen en una versión única específica hasta que se realiza un gesto de actualización explícito.

Para ver en qué modo está la instalación del SDK, ejecute dotnet workload --info:

> dotnet workload --info
Workload version: 9.0.100-manifests.400dd185
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.10.35027.167, VS 17.11.35111.106
   Manifest Version:    8.0.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json
   Install Type:              Msi

En este ejemplo, la instalación del SDK está en modo "manifiesto", donde las actualizaciones se instalan a medida que están disponibles. Para habilitar el nuevo modo, agregue la opción --version a un comando dotnet workload install o dotnet workload update. También puede controlar explícitamente el modo de operación mediante el nuevo dotnet workload config comando:

> dotnet workload config --update-mode workload-set
Successfully updated workload install mode to use workload-set.

Si necesita volver a cambiar por cualquier motivo, puede ejecutar el mismo comando con manifests en lugar de workload-set. También puede usar dotnet workload config --update-mode para comprobar el modo de operación actual.

Para más información, consulte Conjuntos de cargas de trabajo del SDK de .NET.

Historial de cargas de trabajo

Las cargas de trabajo del SDK de .NET son una parte integral de .NET MAUI y Blazor WebAssembly. En su configuración predeterminada, puede actualizar las cargas de trabajo de forma independiente a medida que los autores de herramientas de .NET publiquen nuevas versiones. Además, las instalaciones del SDK de .NET realizadas a través de Visual Studio instalan un conjunto paralelo de versiones. Si no se tiene cuidado, el estado de instalación de la carga de trabajo de una instalación determinada del SDK de .NET puede desviarse con el tiempo, pero no ha habido ninguna forma de visualizar esta desviación.

Para solucionar este problema, .NET 9 agrega un nuevo dotnet workload history comando al SDK de .NET. dotnet workload history imprime una tabla del historial de instalaciones y modificaciones de la carga de trabajo para la instalación actual del SDK de .NET. En la tabla se muestra la fecha de la instalación o modificación, el comando que se ejecutó, las cargas de trabajo que se instalaron o modificaron y las versiones pertinentes para el comando. Esta salida puede ayudarle a comprender el desfase en las instalaciones de cargas de trabajo a lo largo del tiempo y ayudarle a tomar decisiones informadas sobre las versiones de las cargas de trabajo en las que establecer la instalación. Puede considerarlo como git reflog para las cargas de trabajo.

> dotnet workload history

Id  Date                         Command       Workloads                                        Global.json Version  Workload Version
-----------------------------------------------------------------------------------------------------------------------------------------------
1   1/1/0001 12:00:00 AM +00:00  InitialState  android, ios, maccatalyst, maui-windows                               9.0.100-manifests.6d3c8f5d
2   9/4/2024 8:15:33 PM -05:00   install       android, aspire, ios, maccatalyst, maui-windows                       9.0.100-rc.1.24453.3

En este ejemplo, el SDK se instaló inicialmente con las cargas de trabajo android, ios, maccatalyst y maui-windows. A continuación, el dotnet workload install aspire --version 9.0.100-rc.1.24453.3 comando se usó para instalar la aspire carga de trabajo y cambiar al modo de conjuntos de cargas de trabajo. Para volver al estado anterior, puede usar el identificador de la primera columna de la tabla de historial, por ejemplo, dotnet workload update --from-history 1.

Contenedores

• Soporte para la publicación de registros inseguros
• Nomenclatura de variables de entorno

Compatibilidad de publicación para registros no seguros

La compatibilidad integrada con la publicación de contenedores del SDK puede publicar imágenes en registros de contenedor. Hasta .NET 9, esos registros tenían que protegerse; para que el SDK de .NET funcione, necesitaban compatibilidad con HTTPS y certificados válidos. Normalmente, los motores de contenedor se pueden configurar para que funcionen con registros no seguros, es decir, los registros que no tienen TLS configurado o que tengan TLS configurado con un certificado que no sea válido. Este es un caso de uso válido, pero nuestras herramientas no admiten este modo de comunicación.

A partir de .NET 9, el SDK puede comunicarse con registros no seguros.

Requisitos (dependiendo de su entorno):

• Configure la CLI de Docker para marcar un registro como no seguro.
• Configure Podman para marcar un registro como no seguro.
• Use la DOTNET_CONTAINER_INSECURE_REGISTRIES variable de entorno para pasar una lista delimitada por punto y coma de dominios del Registro para tratarlos como no seguros.

Nomenclatura de variables de entorno

Las variables de entorno que las herramientas de publicación de contenedores usan para controlar algunos de los aspectos más finos de la comunicación del Registro y la seguridad ahora comienzan con el prefijo DOTNET en lugar de SDK. El prefijo SDK seguirá siendo compatible en el futuro cercano.

Análisis de código

.NET 9 incluye varios analizadores y solucionadores de código nuevos para ayudar a comprobar que usa las API de biblioteca de .NET de forma correcta y eficaz. En la tabla siguiente se resumen los nuevos analizadores.