Novidades do MSBuild no .NET 11 Preview 1: performance, novas APIs e correções

Resumo de testes sempre reportado

Existia um bug em que o resumo dos testes podia desaparecer da saída do Terminal Logger. Segundo as notas, isso acontecia quando o nó do terminal ficava nulo antes de receber a mensagem de conclusão.

Na prática, o build terminava e o desenvolvedor ficava sem saber se os testes tinham passado ou falhado. A única alternativa era abrir o arquivo de log manualmente.

Agora, o Terminal Logger sempre contabiliza os resultados dos testes no resumo final. Parece uma correção simples, mas faz toda a diferença para quem acompanha o build pelo terminal.

Restauração do status do nó após yield

Quando uma tarefa do MSBuild cedia a execução, operação chamada de yield, o Terminal Logger não restaurava a exibição corretamente. Como resultado, o terminal mostrava informações desatualizadas durante builds complexos.

Imagine um build com vários projetos, em que uma tarefa cede a execução para que outra dependência compile primeiro. Antes da correção, o terminal podia exibir o status anterior do nó, o que confundia quem acompanhava o processo.

Agora, o status de cada nó volta a ficar consistente após o yield. Assim, o que aparece na tela corresponde ao que realmente acontece no build.

Forwarding logger para builds via API

Quem usa as APIs do MSBuild com o Terminal Logger agora tem acesso aos benefícios do forwarding logger em builds com vários nós. Para isso, novos métodos permitem configurar o Terminal Logger como forwarding logger.

Segundo as notas, essa mudança resolve uma lacuna de performance em ferramentas como dotnet run e dotnet watch. Na prática, rodar dotnet watch em projetos grandes tende a gerar uma saída de log mais consistente e com menos overhead.

Encadeamento de funções de item com espaços

Havia um bug no parser em que o encadeamento de funções de item falhava quando existia espaço em branco antes do segundo operador -> ou dos seguintes. Esse tipo de problema frustra, porque o código parece correto visualmente.

Agora, o parser trata corretamente os espaços antes dos operadores. Por exemplo, a expressão abaixo, citada nas notas oficiais, passa a funcionar:

<ItemGroup>
  <!-- encadeamento com espaços antes de cada operador -> -->
  <Filtered Include="@(I -> WithMetadataValue('M', 'T') -> WithMetadataValue('M', 'T'))" />
</ItemGroup>

Se você já perdeu tempo depurando um encadeamento que deveria funcionar, essa pode ter sido a causa.

NoWarn junto com MSBuildWarningsAsMessages

Um bug fazia o MSBuild ignorar a propriedade NoWarn quando MSBuildWarningsAsMessages estava definida. Com isso, o desenvolvedor precisava escolher uma das duas configurações, embora o esperado fosse o funcionamento conjunto.

A correção restaura o comportamento correto. Agora, NoWarn suprime os avisos especificados, enquanto MSBuildWarningsAsMessages converte outros avisos em mensagens informativas.

<PropertyGroup>
  <!-- suprime completamente estes avisos -->
  <NoWarn>$(NoWarn);CS1591</NoWarn>
  <!-- rebaixa estes avisos para mensagens -->
  <MSBuildWarningsAsMessages>MSB3277</MSBuildWarningsAsMessages>
</PropertyGroup>

Elementos com apenas espaços e Regex.Replace

Quando um elemento XML continha apenas espaços em branco, a avaliação do projeto apresentava erros. Esse cenário parece raro, mas surge em arquivos gerados automaticamente ou editados por ferramentas de merge.

Além disso, a invocação de Regex.Replace(...) dentro de property functions produzia resultados errados. Para quem usa expressões regulares em .csproj ou .targets, essa correção evita substituições inesperadas durante o build.

API de parsing de parâmetros do BinaryLogger

O BinaryLogger é o sistema de log binário do MSBuild, que gera arquivos .binlog. Segundo a documentação, esses arquivos guardam propriedades, itens, entradas e saídas de tarefas e o conteúdo dos arquivos importados, o que os torna essenciais para diagnóstico.

O novo método estático BinaryLogger.ParseParameters(string) converte uma string de parâmetros em um objeto tipado BinaryLoggerParameters. Antes dessa API, ferramentas como o dotnet watch precisavam duplicar essa lógica internamente.

// converte a string de parâmetros em um objeto tipado
var parsed = BinaryLogger.ParseParameters("LogFile=build.binlog;ProjectImports=None");

Console.WriteLine(parsed.LogFilePath); // "build.binlog"
Console.WriteLine(parsed.ProjectImportsCollectionMode); // None

O método recebe a string no mesmo formato da linha de comando, como em -bl:build.binlog;ProjectImports=None. Dessa forma, todas as ferramentas que consomem logs binários passam a usar a mesma lógica, sem divergências de comportamento.

Se você trabalha com diagnóstico de builds, o artigo sobre o Binlog MCP Server mostra como analisar esses arquivos com ajuda de IA.

EscapeDataString em property functions

Com o MSBuild no .NET 11, é possível usar System.Uri::EscapeDataString e System.Uri::UnescapeDataString diretamente como property functions. Isso ajuda quando você precisa codificar valores para URLs dentro de arquivos de projeto.

Antes dessa adição, a alternativa era criar uma tarefa customizada ou chamar um script externo. Agora, basta usar a sintaxe nativa:

<PropertyGroup>
  <QueryParam>hello world &amp; test=123</QueryParam>
  <Encoded>$([System.Uri]::EscapeDataString($(QueryParam)))</Encoded>
  <!-- Resultado: hello%20world%20%26%20test%3D123 -->
</PropertyGroup>

A propriedade Encoded passa a conter a string codificada corretamente. Ou seja, espaços, o "e comercial" e o sinal de igual viram suas representações percentuais, prontas para uso em URLs.

Modo transacional no WriteLinesToFile

No MSBuild do .NET 11, a tarefa WriteLinesToFile escreve e acrescenta conteúdo de forma transacional. Essa mudança resolve um problema real de builds paralelos, em que várias instâncias do MSBuild tentam escrever no mesmo arquivo ao mesmo tempo.

Antes, o resultado era imprevisível: às vezes o conteúdo corrompia, às vezes um processo sobrescrevia o outro. Em alguns casos, o build falhava com erro de acesso ao arquivo.

Segundo as notas, a tarefa agora cria arquivos novos em um local temporário e depois os move de forma atômica. Já nas operações de acréscimo, ela usa handles com FileShare.Read, evitando conflitos de escrita concorrente.

MSBUILDDEBUGONSTART=3 para task hosts

A variável de ambiente MSBUILDDEBUGONSTART controla o comportamento de depuração do MSBuild. O novo valor 3 pula os prompts para anexar o depurador nos processos filhos do TaskHost.

Isso ajuda em cenários de depuração automatizada, em que você quer investigar o processo principal sem interrupções. Em builds que usam task hosts para isolar tarefas, essa opção economiza bastante tempo.

Estruturas de dados otimizadas

Várias estruturas de dados internas mudaram para aproveitar melhor o cache e alocar menos memória. Esse tipo de ajuste parece pequeno, mas o MSBuild executa essas estruturas milhares de vezes por build.

ItemDictionary trocou a LinkedList por uma estrutura mais amigável ao cache da CPU. Afinal, cada nó de uma lista ligada pode ficar em uma região diferente do heap, enquanto dados contíguos aproveitam melhor as linhas de cache do processador.

Lookup.Scope ganhou uma nova implementação das tabelas de escopo, com buscas mais rápidas. Como o MSBuild avalia escopos intensamente, essa otimização tem efeito em cascata em toda a avaliação de projetos.

WorkUnitResult deixou de ser classe e virou struct, o que elimina uma alocação no heap para cada unidade de trabalho. Em builds com milhares de tarefas, isso reduz a pressão sobre o garbage collector.

Menos alocações no MSBuild do .NET 11

No MSBuild do .NET 11, diversas operações também passaram a evitar alocações desnecessárias no heap:

• ProjectMetadataInstance eliminou alocações que o fluxo normal de avaliação não exigia.
• LazyItemEvaluator evita o boxing de enumeradores, que ocorre quando um value type vira reference type.
• GetEnumerator ganhou uma verificação de ICollection<T> que evita alocações em cenários comuns.
• A otimização de captura única em regex trata de forma direta o caso mais comum, com apenas uma captura.

Otimizações de I/O e logging

O buffer de log do nó RAR, sigla de ResolveAssemblyReference, armazena eventos antes de enviá-los. Como essa tarefa é uma das que mais geram log, a mudança beneficia builds com muitas referências de assembly.

Além disso, a abstração FileSystems passou a substituir chamadas diretas à BCL nas operações de arquivo. Com isso, o time ganha espaço para otimizações por plataforma e para testes unitários mais eficientes do motor de build.

Outras otimizações notáveis

• EndsWith ganhou um caminho rápido para chamadas com StringComparison.
• ImmutableDictionary.SetItems usa o padrão builder em atualizações em lote, sem dicionários intermediários.
• Cópias de metadados RAR mudaram de ordem para priorizar os caminhos mais frequentes.
• BuildGlobResultFromIncludeItem simplificou a construção dos resultados de glob.
• Lookup.ExplicitModifications passou a usar um tipo concreto de dicionário, sem o custo de dispatch virtual.

Estabilidade do build

O DrainPacketQueue tinha um possível travamento de thread após a conclusão do build. O processo ficava pendurado, sem erro e sem timeout, o que desperdiça agentes em pipelines de CI/CD.

Já os loops infinitos de depuração surgiam com o redirecionamento da pasta temporária por variáveis de ambiente. Portanto, se você customiza TEMP ou TMP no ambiente de build, essa correção interessa diretamente.

Por fim, o crash no Preprocess acontecia com a opção /preprocess, ou /pp. Essa opção gera uma versão expandida do projeto com todas as importações resolvidas e agora funciona de forma estável.

Compatibilidade entre plataformas

Em sistemas Unix, como Linux e macOS, o sistema de arquivos diferencia maiúsculas de minúsculas, e o MSBuild no .NET 11 passa a respeitar isso. A tarefa Copy não respeitava essa diferença corretamente, e a correção garante o tratamento adequado dos nomes de arquivos.

Além disso, os arquivos de solution filter, com extensão .slnf, agora aceitam separadores Unix e Windows. Isso facilita o trabalho em equipes que usam sistemas operacionais diferentes.

Resolução e depuração

Os erros em app.config agora incluem o número da linha na mensagem. Antes, a mensagem apenas indicava um problema no arquivo, sem informar a localização exata.

A resolução de assemblies também recebeu correção para arquivos .exe e tarefas legadas do .NET Framework. Assim, projetos que ainda dependem desses componentes continuam funcionando na nova versão.

Já a resolução de arquivos em inline tasks agora parte do diretório do projeto, e não do diretório de trabalho atual. Antes, o mesmo build podia funcionar ou falhar dependendo da pasta em que você executava o comando.

Outras correções do MSBuild no .NET 11

• DistributedFileLogger: corrigido o erro MSB1025 ao usar a flag -dfl.
• Determinismo do deps.json: a seção de recursos agora tem ordenação determinística, o que favorece builds reproduzíveis.
• /getItem e /getTargetResult: deixaram de lançar exceções não tratadas com caracteres ilegais no caminho.
• SDK resolver: ganhou um mecanismo de fallback para quando a API externa do resolver não está disponível.
• Variáveis de ambiente do SDK: o log registra apenas valores diferentes do padrão, com menos ruído.