Compartilhar via

Novidades no SDK e ferramentas para .NET 9

  • Artigo

Este artigo descreve novos recursos no SDK do .NET e ferramentas para .NET 9.

Teste de unidade

Esta seção descreve as atualizações dos testes de unidade no .NET 9: a execução de testes em paralelo e a saída de teste do registrador de terminal.

Executar testes em paralelo

No .NET 9, dotnet test é mais totalmente integrado ao MSBuild. Como o MSBuild dá suporte à criação em paralelo, você pode executar testes para o mesmo projeto em estruturas de destino diferentes em paralelo. Por padrão, o MSBuild limita o número de processos paralelos ao número de processadores no computador. Você também pode definir seu próprio limite usando a opção -maxcpucount. Se você quiser recusar o paralelismo, defina a propriedade TestTfmsInParallel MSBuild como false.

Exibição de teste do agente de terminal

O relatório de resultados de teste para dotnet test agora é suportado diretamente no registrador do terminal do MSBuild. Você obtém relatórios de teste mais completos enquanto os testes de estão em execução (exibe o nome do teste em execução) e após a conclusão dos testes de (todos os erros de teste são renderizados de uma maneira melhor).

Para obter mais informações sobre o registrador de terminal, consulte opções de dotnet build.

Roll-forward de ferramenta do .NET

Ferramentas do .NET são aplicativos dependentes de framework que podem ser instalados localmente ou globalmente e, em seguida, executados usando o SDK do .NET e as runtimes do .NET instaladas. Essas ferramentas, como todos os aplicativos .NET, têm como destino uma versão principal específica do .NET. Por padrão, os aplicativos não são executados em versões mais recentes do .NET. Os autores de ferramentas foram capazes de aceitar a execução de suas ferramentas em versões mais recentes do runtime do .NET definindo a propriedade RollForward MSBuild. No entanto, nem todas as ferramentas fazem isso.

Uma nova opção para dotnet tool install permite que usuários decidam como as ferramentas do .NET devem ser executadas. Ao instalar uma ferramenta por meio de dotnet tool installou ao executar a ferramenta por meio de dotnet tool run <toolname>, você pode especificar um novo sinalizador chamado --allow-roll-forward. Essa opção configura a ferramenta com o modo avanço contínuo Major. Esse modo permite que a ferramenta seja executada em uma versão principal mais recente do .NET se a versão do .NET correspondente não estiver disponível. Esse recurso ajuda os primeiros adotantes a usar ferramentas do .NET sem que os autores de ferramentas precisem alterar nenhum código.

Registrador de terminal

O agente de terminal agora está habilitado por padrão e também teve a usabilidade melhorada.

Habilitado por padrão

A partir do .NET 9, a experiência padrão para todos os comandos do CLI do .NET que usam o MSBuild é o registrador de terminal, a experiência de log aprimorada lançada no .NET 8. Essa nova saída usa os recursos dos terminais modernos para fornecer funcionalidades como:

  • Links clicáveis
  • Temporizadores de duração para tarefas do MSBuild
  • Codificação de cores de mensagens de aviso e erro

A saída é mais condensada e útil do que o agente de console do MSBuild existente.

O novo registrador tenta detectar automaticamente se ele pode ser usado, mas você também pode controlar manualmente se o registrador de terminal é usado. Especifique a opção de linha de comando --tl:off para desabilitar o registrador de terminal para um comando específico. Ou, para desabilitar o logger de terminal de forma mais ampla, defina a variável de ambiente MSBUILDTERMINALLOGGER como off.

O conjunto de comandos que usa o registrador de terminal por padrão é:

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

Usabilidade

O logger do terminal agora resume a contagem total de falhas e avisos no final de um processo de build. Ela também mostra os erros que contêm novas linhas. (Para obter mais informações sobre o agente de terminal, consulte Opções de "dotnet build", especificamente a opção --tl).

Considere o seguinte arquivo de projeto que emite um aviso quando o projeto é criado:

<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>

Quando você executa dotnet build -tl no SDK do .NET 8, a saída é mostrada seguindo este parágrafo. Cada linha do aviso de várias linhas é uma linha separada com um prefixo de mensagem de erro completo na saída, que é difícil de ler. Além disso, o resumo final da compilação diz que houve avisos, mas não quantos eram. As informações ausentes podem dificultar a determinação de se um build específico é melhor ou pior do que os builds 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

Quando você cria o mesmo projeto usando o SDK do .NET 9, a saída é a seguinte:

> 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

As linhas de mensagem do aviso não têm mais as informações de projeto e local repetidas que bagunçam a exibição. Além disso, o resumo do build mostra quantos avisos (e erros, se houver algum) foram gerados durante o build.

Se você tiver comentários sobre o logger do terminal, poderá enviá-los no repositório MSBuild .

Resolução de dependência do NuGet mais rápida para repositórios grandes

O resolvedor de dependência do NuGet foi revisado para melhorar o desempenho e a escalabilidade de todos os projetos <PackageReference>. Habilitado por padrão, o novo algoritmo acelera as operações de restauração sem comprometer a funcionalidade, aderindo estritamente às regras principais de resolução de dependência.

Se encontrar problemas, como falhas de restauração ou versões de pacote inesperadas, você poderá reverter para o resolvedor herdado.

Analisadores de script do MSBuild ("BuildChecks")

O .NET 9 apresenta um recurso que ajuda a proteger contra defeitos e regressões em seus scripts de build. Para executar as verificações de build, adicione o sinalizador /check a qualquer comando que invoque o MSBuild. Por exemplo, dotnet build myapp.sln /check cria a solução myapp e executa todas as verificações de build configuradas.

O SDK do .NET 9 inclui um pequeno número de verificações iniciais, por exemplo, BC0101 e BC0102. Para obter uma lista completa, consulte os códigos do BuildCheck .

Quando um problema é detectado, um diagnóstico é produzido na saída de build para o projeto que contém o problema.

Para obter mais informações, consulte a documentação de design .

Incompatibilidade do analisador

Muitos usuários instalam o SDK do .NET e o Visual Studio em diferentes cadências. Embora essa flexibilidade seja desejável, ela pode levar a problemas para ferramentas que precisam interoperar entre os dois ambientes. Um exemplo desse tipo de ferramenta é o Roslyn Analyzers. Os autores do analisador precisam codificar para versões específicas do Roslyn, mas quais versões estão disponíveis e quais são usadas por uma determinada compilação às vezes não são claras.

Esse tipo de incompatibilidade de versão entre o SDK do .NET e o MSBuild é conhecido como um SDK dividido. Quando você estiver nesse estado, poderá ver erros como este:

CSC: aviso CS9057: o assembly do analisador '..\dotnet\sdk\8.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators.dll' faz referência à versão '4.9.0.0' do compilador, que é mais recente do que a versão atualmente em execução '4.8.0.0'.

O .NET 9 pode detectar e ajustar-se automaticamente para esse cenário de problema. A lógica do MSBuild do SDK insere a versão do MSBuild com a qual ele foi enviado e essas informações podem ser usadas para detectar quando o SDK está em execução em um ambiente com uma versão diferente. Quando isso acontece, o SDK insere um download implícito de um pacote de suporte chamado Microsoft.Net.Sdk.Compilers.Toolset que garante uma experiência de analisador consistente.

Conjuntos de cargas de trabalho

Conjuntos de Cargas de Trabalho é um recurso do SDK destinado a dar aos usuários mais controle sobre as cargas de trabalho que instalam e sobre a cadência das mudanças dessas cargas de trabalho. Nas versões anteriores, as cargas de trabalho eram atualizadas periodicamente à medida que novas versões de cargas de trabalho individuais eram lançadas em qualquer feed do NuGet configurado. Agora, todas as suas cargas de trabalho permanecem em uma versão única específica até que você faça um gesto de atualização explícito.

Você pode ver em que modo a instalação do SDK está ao executar 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

Neste exemplo, a instalação do SDK está no modo "manifesto", em que as atualizações são instaladas conforme estão disponíveis. Para aceitar o novo modo, adicione uma opção --version a um comando dotnet workload install ou dotnet workload update. Você também pode controlar explicitamente seu modo de operação usando o novo comando dotnet workload config:

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

Se você precisar alterar de volta por qualquer motivo, poderá executar o mesmo comando com manifests em vez de workload-set. Você também pode usar dotnet workload config --update-mode para verificar o modo de operação atual.

Para obter mais informações, consulte Conjuntos de cargas de trabalho do SDK do .NET.

Histórico de carga de trabalho

As cargas de trabalho do SDK do .NET são parte integrante do .NET MAUI e Blazor WebAssembly. Na configuração padrão, você pode atualizar cargas de trabalho de forma independente, pois os autores de ferramentas do .NET lançam novas versões. Além disso, as instalações do SDK do .NET feitas por meio do Visual Studio instalam um conjunto paralelo de versões. Sem tomar cuidado, o status de instalação da carga de trabalho de uma determinada instalação do SDK do .NET pode se alterar ao longo do tempo, mas não existe uma forma de visualizar essa alteração.

Para resolver isso, o .NET 9 adiciona um novo comando dotnet workload history ao SDK do .NET. dotnet workload history imprime uma tabela do histórico de instalações e modificações da carga de trabalho para a instalação atual do SDK do .NET. A tabela mostra a data da instalação ou modificação, o comando que foi executado, as cargas de trabalho que foram instaladas ou modificadas e as versões relevantes para o comando. Essa saída pode ajudá-lo a entender a variação nas instalações de cargas de trabalho ao longo do tempo e a tomar decisões informadas sobre quais versões de cargas de trabalho escolher para sua instalação. Você pode pensar nisso como git reflog para cargas de trabalho.

> 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

Neste exemplo, o SDK foi inicialmente instalado com as cargas de trabalho android, ios, maccatalyste maui-windows. Em seguida, o comando dotnet workload install aspire --version 9.0.100-rc.1.24453.3 foi usado para instalar a carga de trabalho aspire e mudar para o modo de conjuntos de carga de trabalho. Para retornar ao estado anterior, você pode usar a ID da primeira coluna na tabela de histórico, por exemplo, dotnet workload update --from-history 1.

Contêineres

Suporte de publicação para registros inseguros

O suporte de publicação de contêiner interno do SDK pode publicar imagens em registros de contêiner. Até o .NET 9, esses registros eram necessários para serem protegidos, para que o SDK do .NET funcionasse, eles precisavam de suporte HTTPS e certificados válidos. Os mecanismos de contêiner geralmente também podem ser configurados para trabalhar com registros inseguros, ou seja, registros que não têm O TLS configurado ou têm o TLS configurado com um certificado inválido. Esse é um caso de uso válido, mas nossas ferramentas não dão suporte a esse modo de comunicação.

A partir do .NET 9, o SDK pode se comunicar com registros inseguros.

Requisitos (dependendo do seu ambiente):

  • Configure a CLI do Docker para marcar um registro como inseguro.
  • Configure o Podman para marcar um registro como inseguro.
  • Use a variável de ambiente DOTNET_CONTAINER_INSECURE_REGISTRIES para passar uma lista delimitada por ponto-e-vírgula de domínios de registro para serem tratados como inseguros.

Nomenclatura de variáveis de ambiente

As variáveis de ambiente que a ferramenta de publicação de contêiner usa para controlar alguns dos aspectos mais finos da comunicação e segurança do Registro agora começam com o prefixo DOTNET em vez de SDK. O prefixo SDK continuará a ser suportado no curto prazo.

Análise de código

O .NET 9 inclui vários novos analisadores de código e corretores para ajudar a verificar se você está usando as APIs das bibliotecas do .NET de forma correta e eficiente. A tabela a seguir resume os novos analisadores.

ID da regra Categoria Descrição
CA1514: evite argumento de comprimento redundante Manutenibilidade Um argumento de comprimento explicitamente calculado pode ser propenso a erros e é desnecessário quando você está fatiando para o final de uma cadeia de caracteres ou buffer.
CA1515: Considere tornar os tipos públicos internos Manutenibilidade Os tipos dentro de um assembly executável devem ser declarados como internal.
CA1871: Não passe uma estrutura anulável para 'ArgumentNullException.ThrowIfNull' Desempenho Para melhorar o desempenho, é melhor verificar a propriedade HasValue e lançar manualmente uma exceção do que passar um struct nulo para ArgumentNullException.ThrowIfNull.
CA1872: prefira "Convert.ToHexString" e "Convert.ToHexStringLower" em vez de cadeias de chamadas baseadas em "BitConverter.ToString" Desempenho Use Convert.ToHexString ou Convert.ToHexStringLower ao codificar bytes em uma representação de cadeia de caracteres hexadecimal.
CA2022: evite leitura imprecisa com Stream.Read Fiabilidade Uma chamada para Stream.Read pode retornar menos bytes do que a solicitada, resultando em código não confiável se o valor retornado não for verificado.
CA2262: Defina 'MaxResponseHeadersLength' corretamente Uso A propriedade HttpClientHandler.MaxResponseHeadersLength é medida em quilobytes, não em bytes.
CA2263: prefira sobrecarga genérica quando o tipo é conhecido Uso Sobrecargas genéricas são preferíveis a sobrecargas que aceitam um argumento do tipo System.Type quando o tipo é conhecido em tempo de compilação.
CA2264: não passe um valor não anulável para 'ArgumentNullException.ThrowIfNull' Uso Certos constructos, como structs não anuláveis (exceto por Nullable<T>), expressões "nameof()" e expressões "new", são conhecidas por nunca serem nulas; portanto, ArgumentNullException.ThrowIfNull nunca será lançada.
CA2265: não compare Span<T> com nulo ou padrão Uso Comparar um trecho com null ou default pode não fazer o que se pretendia. default e o literal null são convertidos implicitamente em Span<T>.Empty. Remova a comparação redundante ou torne o código mais explícito usando IsEmpty.