Lançado o .NET 11 Preview 5

Suporte a dispositivos no dotnet run com MAUI

Durante anos, o dotnet run foi a espinha dorsal do ciclo de desenvolvimento. No .NET 10, os projetos ganharam formas de customizar a execução, o que viabilizou, por exemplo, a integração com o emulador do Azure Functions.

Com o .NET 11, a equipe do MAUI levou o dotnet run para dispositivos físicos e simuladores. Antes, executar um app MAUI exigia compilar, gerar o pacote de instalação, enviá-lo ao dispositivo e iniciar o app remotamente.

Agora, o comando lista os dispositivos disponíveis e escolhe o target framework correto para cada um. Em seguida, ele faz todo o ciclo de deploy e inicialização de forma integrada.

Além disso, o protocolo de descoberta de dispositivos é extensível. Assim, frameworks como Uno e Avalonia também podem adotá-lo.

Contexto de agente na CLI do .NET 11 Preview 5

Uma das adições mais relevantes para o desenvolvimento assistido por IA é a detecção de contexto de agente. Na prática, a CLI percebe quando roda dentro de ferramentas como Claude Code ou GitHub Copilot.

A detecção usa heurísticas e, quando identifica um agente, a CLI muda a forma de renderizar a saída. Com isso, ela também reduz o consumo desnecessário de tokens.

Um bom exemplo é o terminal logger, display de build padrão desde o .NET 10. Ele tem uma seção estática com as saídas dos projetos e uma seção dinâmica que atualiza o progresso o tempo todo.

Para um agente LLM, essa seção dinâmica desperdiça tokens. Por isso, a CLI desativa a atualização ao vivo quando opera sob um agente, e no .NET 11 Preview 5 o dotnet test também desliga a saída ANSI nesses ambientes.

Outro cenário envolve os work trees do Git, que agentes usam para trabalhar em várias branches em paralelo. Antes, vários processos de dotnet build na mesma máquina não sabiam uns dos outros e disputavam recursos.

Nesse sentido, a equipe investiga um gateway centralizado no MSBuild para coordenar builds paralelos.

MSBuild com suporte a múltiplas threads

Historicamente, o MSBuild usa uma arquitetura com vários processos. Ela oferece bom isolamento, mas cobra caro na comunicação entre processos e no carregamento repetido do JIT.

O .NET 11 avança para um modo com várias threads dentro de um único processo. Quando a apresentação aconteceu, esse modo ainda não estava disponível, mas a meta é entregá-lo no lançamento oficial.

Portanto, autores de tasks do MSBuild devem acompanhar a documentação sobre como atualizar tasks para o modo multithread.

Ferramentas embarcadas já compiladas com AOT

Ferramentas embarcadas como user-secrets, dev-certs e o gerenciador de JWT já usam Native AOT. Em uma máquina Windows, o dotnet user-secrets levou em média 54 milissegundos, e apenas 14 milissegundos foram o código da aplicação.

O restante foi overhead da CLI gerenciada. Ou seja, o ganho cresce à medida que mais comandos fizerem a transição.

O argumento vai além do desempenho imediato, pois a CLI roda dezenas de vezes por dia. Assim, cada economia de 100 milissegundos por comando se multiplica.

Também existe um ganho para o ecossistema. Várias bibliotecas da Microsoft não suportavam trim ou AOT, e transformar a CLI em aplicação AOT forçou a equipe a remover esses bloqueios.

No ciclo do .NET 11, bibliotecas de templating, o NuGet e partes do MSBuild ficaram mais amigáveis ao trimming. Com isso, a comunidade publica aplicações trim e AOT com mais facilidade.

Observabilidade via OpenTelemetry

Com o Native AOT, a CLI também passou a emitir telemetria via OpenTelemetry. Dessa forma, você usa o Aspire Dashboard para inspecionar a execução dos comandos com rastreamento distribuído.

O dashboard exibe os spans nativos da CLI separados dos spans da parte gerenciada. Assim, você enxerga com detalhe o desempenho de cada operação.

Nova API para gerenciamento de processos

A API de Process sempre gerou bugs, sobretudo ao capturar StandardOutput e StandardError de forma síncrona. O problema clássico era um deadlock quando um dos buffers enchia enquanto o código esperava o outro terminar.

O .NET 11 introduz APIs de conveniência que resolvem isso com segurança:

• RunAndCaptureTextAsync devolve um ProcessTextOutput com saída, erro e código de saída, sem risco de deadlock.
• ReadAllLinesAsync percorre as linhas de forma assíncrona e indica se cada linha veio de StandardError.
• SafeFileHandle.CreateAnonymousPipe viabiliza pipes entre processos, como o | dos shells Unix.
• Um modo fire-and-forget atende quem não precisa esperar o processo e permite encerrar o filho junto com o pai.

using System.Diagnostics;

// captura saída, erro e código de saída em uma única chamada
ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
    "git", ["status", "--porcelain"]);

Console.WriteLine(result.StandardOutput);
Console.WriteLine($"Exit code: {result.ExitStatus.ExitCode}");

Há também o SafeProcessHandle, pensado para cenários com trim e AOT no .NET 11 Preview 5. No Preview 5, a leitura de linhas de processos também recebeu melhorias.

Texto, Unicode e System.Text.Json

O .NET 11 adiciona IsValid e IndexOfInvalidSubsequence para UTF-8 e UTF-16. Assim, você verifica se um texto externo está bem codificado e descobre exatamente onde está a sequência inválida.

Outra adição é a opção AnyNewLine no Regex, que faz o . reconhecer qualquer variante de quebra de linha. Além disso, métodos de string passaram a operar corretamente sobre runas Unicode, algo essencial com emojis.

O System.Text.Json ganha atributos para configurar políticas de serialização por tipo. Por exemplo, uma classe pode deixar de emitir propriedades null com um único atributo e combinar convenções de nomenclatura diferentes por campo.

No .NET 11 Preview 5, o serializador também suporta JSON Lines, formato com um documento JSON por linha. Na prática, você usa JsonSerializer.SerializeAsyncEnumerable com topLevelValues: true:

// grava cada item como uma linha JSON independente
await JsonSerializer.SerializeAsyncEnumerable(
    stream, GetEventsAsync(), topLevelValues: true);

O formato aparece muito em logs de conversas de agentes e em pipelines de streaming.

Compressão com Zstandard

No .NET 11 Preview 5, as APIs do Zstandard (ZStd) já fazem parte do produto, sem as dependências externas de antes. Nos benchmarks de texto, o ZStd ficou próximo do Brotli em taxa de compressão e velocidade.

Agora ele aparece como opção de primeira classe, ao lado de Deflate, GZip e Brotli.

Como habilitar o Runtime Async

Para habilitar o recurso, basta adicionar uma propriedade ao arquivo de projeto:

<PropertyGroup>
  <Features>runtime-async=on</Features>
</PropertyGroup>

Projetos com target net11.0 não precisam mais de <EnablePreviewFeatures>true</EnablePreviewFeatures>. Além disso, as bibliotecas do runtime já usam runtime-async=on e servem como validação ampla do recurso.

No .NET 11 Preview 5, o runtime otimiza a suspensão e a retomada e retoma métodos diretamente em código otimizado. Segundo a cobertura da Visual Studio Magazine, um benchmark com muitas suspensões caiu de 6.357,1 para 457,1 milissegundos graças à otimização de On-Stack Replacement.

Benefícios observáveis

O impacto mais visível está nos stack traces ao vivo. No modelo tradicional, um método assíncrono aninhado em outros gera dezenas de frames de infraestrutura.

Com o Runtime Async, o stack trace mostra apenas os métodos reais da aplicação. Isso beneficia profilers, loggers de diagnóstico e depuradores.

Os breakpoints também funcionam dentro desses métodos, e o depurador atravessa os await sem entrar em código gerado. Por outro lado, o runtime reutiliza objetos de continuação e evita salvar variáveis locais inalteradas, o que reduz alocações.

O recurso é compatível com Native AOT e ReadyToRun. Além disso, código com e sem Runtime Async se chama livremente, então nada quebra quando o recurso virar padrão no .NET 12.

Para um mergulho maior nesse tema, veja as novidades do runtime no Preview 5.