Novidades do .NET 11 Preview 1: Hot Reload, dotnet run interativo e novos Code Analyzers

Seleção interativa de target framework

Ao executar um projeto multi-targeted sem a flag --framework, o dotnet run exibe um menu interativo. Você escolhe o target framework desejado usando as teclas de seta.

Essa interface usa a biblioteca Spectre.Console, conhecida por montar prompts e tabelas ricas no terminal. Portanto, a experiência fica parecida com a de outras ferramentas modernas de linha de comando.

Em terminais não interativos, o comportamento também melhorou. Em vez de falhar de forma pouco clara, o comando exibe um erro formatado que lista os frameworks disponíveis.

Na prática, isso elimina a tentativa e erro em scripts e pipelines. Afinal, a própria mensagem já mostra quais valores você pode passar em --framework.

Seleção de dispositivos para .NET MAUI

Se você desenvolve com .NET MAUI, essa novidade muda o fluxo de trabalho pela linha de comando. O dotnet run agora suporta seleção de dispositivos para workloads mobile e embarcados.

Projetos que implementam o target MSBuild ComputeAvailableDevices expõem automaticamente os dispositivos, emuladores e simuladores disponíveis. Os workloads de iOS e Android já fornecem esse target.

Quando existem vários dispositivos, o dotnet run pede que você escolha um interativamente. Além disso, dois novos switches entram em cena:

• --device: especifica o dispositivo alvo diretamente, sem prompt interativo.
• --list-devices: lista os dispositivos disponíveis sem executar a aplicação.

# Lista os dispositivos, emuladores e simuladores disponíveis
dotnet run --list-devices

# Executa direto em um dispositivo conhecido, sem prompt
dotnet run --device <device-id>

O RuntimeIdentifier do dispositivo escolhido segue automaticamente para as etapas de build, deploy e execução. Se o projeto definir o target DeployToDevice, o dotnet run também cuida do deploy.

Com isso, você ganha um pipeline completo de build, deploy e run pela CLI. A especificação do dotnet run para MAUI descreve esse contrato em detalhes.

Essa extensibilidade não é exclusiva do MAUI. Qualquer projeto que forneça os targets MSBuild necessários pode usar a seleção interativa de dispositivos.

Novas referências sem reiniciar a aplicação

Essa é provavelmente a melhoria mais aguardada. Até o .NET 10, adicionar um PackageReference ou ProjectReference durante uma sessão de Hot Reload exigia reiniciar a aplicação.

No .NET 11 Preview 1, isso não é mais necessário. Quando você adiciona uma referência durante uma sessão do dotnet watch, o fluxo segue três passos:

1. O Roslyn valida a alteração e determina quais projetos precisam de nova implantação.
2. Em seguida, o dotnet watch executa o target ReferenceCopyLocalPathsOutputGroup para copiar as novas dependências para o diretório de saída.
3. Por fim, o delta applier na aplicação em execução carrega os novos assemblies pelo evento AssemblyResolving.

<ItemGroup>
  <!-- Adicionada com o dotnet watch rodando: não exige mais reinício -->
  <PackageReference Include="Humanizer" Version="2.14.1" />
  <ProjectReference Include="..\Billing\Billing.csproj" />
</ItemGroup>

Dessa forma, você itera em soluções com vários projetos sem interrupções. O estado da aplicação também se mantém, o que é um ganho real de produtividade.

Porta do WebSocket do dotnet watch no Docker

Uma nova variável de ambiente, DOTNET_WATCH_AUTO_RELOAD_WS_PORT, fixa a porta do WebSocket usado pelo dotnet watch. Esse canal serve para atualizar o navegador quando o conteúdo muda.

Isso é particularmente útil com Docker e contêineres, onde você precisa definir regras de port forwarding antecipadamente. Antes, a porta podia variar entre execuções, o que dificultava o mapeamento.

# Fixa o WebSocket de atualização do navegador em uma porta específica
export DOTNET_WATCH_AUTO_RELOAD_WS_HOSTNAME=0.0.0.0
export DOTNET_WATCH_AUTO_RELOAD_WS_PORT=6123
dotnet watch

A variável complementa a já existente DOTNET_WATCH_AUTO_RELOAD_WS_HOSTNAME, que define o host do WebSocket. Essa melhoria veio da comunidade, com contribuição de @wes-sleeman.

CA1517: ReadOnlySpan de char para constantes

Quando você tem valores constantes do tipo string, o analisador sugere trocar por ReadOnlySpan<char>. O objetivo é evitar alocações desnecessárias no heap.

CA1830: StringBuilder.Append(char)

A regra detecta chamadas como StringBuilder.Append(new string(char, int)). Em seguida, sugere o uso direto de StringBuilder.Append(char), que é mais eficiente.

CA1876: AsParallel() em foreach

Essa regra identifica chamadas de AsParallel() em loops foreach que anulam o paralelismo. O foreach consome os itens de forma sequencial, então o custo do PLINQ entra sem trazer o benefício esperado.

É um erro sutil, mas com impacto significativo em performance. Por isso, vale revisar os pontos que o analisador apontar.

CA1877: Path.Combine e Path.Join aninhados

A regra detecta chamadas aninhadas como Path.Combine(Path.Combine(a, b), c). Então, sugere consolidar tudo em uma única chamada, o que reduz alocações e chamadas de função.

public string GetFilePath(string folder, string subfolder, string fileName)
{
    // Violação: duas chamadas consecutivas
    string temp = Path.Combine(folder, subfolder);
    return Path.Combine(temp, fileName);
}

public string GetFilePathFixed(string folder, string subfolder, string fileName)
{
    // Correção: uma única sobrecarga com todos os segmentos
    return Path.Combine(folder, subfolder, fileName);
}

CA2026: JsonElement.Parse

Se você usa JsonDocument.Parse() apenas para acessar o RootElement, o analisador sugere JsonElement.Parse diretamente. Esse método surgiu no .NET 10 e evita o JsonDocument intermediário.

O detalhe importa porque JsonDocument implementa IDisposable e aluga arrays do ArrayPool<T>. Quando ninguém faz o dispose, a pressão sobre o GC aumenta.

public static void ProcessJson(string json)
{
    // Violação: o JsonDocument nunca recebe Dispose
    JsonElement before = JsonDocument.Parse(json).RootElement;

    // Correção: parse direto para JsonElement
    JsonElement after = JsonElement.Parse(json);
}

CA2027: Task.Delay não cancelável em Task.WhenAny

A última regra identifica cenários em que Task.Delay aparece sem CancellationToken dentro de Task.WhenAny. Esse padrão é comum para implementar timeouts.

Sem o token, o Task.Delay continua rodando mesmo depois que o WhenAny completa. Isso desperdiça recursos e pode virar fonte de bugs.

O exemplo abaixo, escrito para este artigo, ilustra a correção. Nele, o cancelamento libera o timer assim que o download termina primeiro.

public static async Task<string?> DownloadWithTimeoutAsync(HttpClient client, string url)
{
    using var cts = new CancellationTokenSource();
    Task<string> download = client.GetStringAsync(url);

    // Com o token, o delay pode ser cancelado quando o download termina antes
    Task delay = Task.Delay(TimeSpan.FromSeconds(3), cts.Token);

    Task finished = await Task.WhenAny(download, delay);
    cts.Cancel();

    return finished == download ? await download : null;
}

Opt-out da codificação UTF-8 no console

O MSBuild configura automaticamente a codificação do console para UTF-8. Contudo, em sistemas em japonês ou chinês, isso pode gerar texto ilegível quando você redireciona a saída para um pipe.

A nova variável de ambiente DOTNET_CLI_FORCE_UTF8_ENCODING permite desativar esse comportamento:

# No Windows (cmd)
set DOTNET_CLI_FORCE_UTF8_ENCODING=false
dotnet build

Apps baseados em arquivo com o mesmo comportamento de projetos

Aplicações baseadas em arquivo, como em dotnet build app.cs, agora seguem os mesmos padrões de verbosidade de projetos tradicionais. Assim, a saída fica igual à de dotnet build MyProject.csproj.

Esse alinhamento parece pequeno, mas evita surpresas. Afinal, quem começa com um arquivo solto e depois migra para um projeto espera a mesma experiência.