.NET 11 preview 5: Novidades no SDK e ferramentas
O .NET 11 Preview 5 marca uma etapa importante no ciclo da plataforma, com melhorias significativas no SDK, na CLI e nas ferramentas de produtividade.
As novidades vão das aplicações baseadas em arquivo ao template MCP Server no dotnet new. Além disso, a versão avança rumo a uma CLI compilada com NativeAOT.
Este artigo detalha cada funcionalidade introduzida nessa versão, com exemplos práticos e uma análise do impacto para quem desenvolve com .NET.
Apps baseados em arquivo no .NET 11 Preview 5
As aplicações baseadas em arquivo permitem rodar um único arquivo .cs com dotnet run, sem criar um projeto formal. No .NET 11 Preview 5, elas ganham uma das novidades mais relevantes para o fluxo de trabalho moderno: dividir o código entre vários arquivos.
A nova diretiva #:ref
A nova diretiva #:ref permite que um arquivo referencie outro aplicativo baseado em arquivo como biblioteca. Além disso, referências transitivas também funcionam, o que viabiliza hierarquias de dependência sem qualquer configuração de projeto.
// app.cs
#:ref lib.cs
Console.WriteLine(MyLib.Greeter.Greet("World"));
// lib.cs
namespace MyLib;
public static class Greeter
{
public static string Greet(string name) => $"Hello, {name}!";
}
Nesse exemplo, o app.cs usa a classe Greeter definida no lib.cs. Assim, você organiza o código em arquivos menores sem abrir mão da simplicidade do script.
Diretivas #:include e #:exclude sem feature flag
As diretivas #:include e #:exclude foram promovidas nesta versão e não exigem mais feature flags. Da mesma forma, diretivas dentro de arquivos incluídos agora são processadas de forma transitiva, também sem flag.
A equipe também passou a permitir entradas duplicadas de #:project e #:ref, alinhando o comportamento ao dos itens do MSBuild. Por outro lado, outras diretivas duplicadas entre arquivos incluídos agora geram um diagnóstico, em vez de serem aceitas em silêncio.
Para entender como esse recurso começou, leia as novidades do SDK no .NET 11 Preview 1, que trouxe as primeiras mudanças no dotnet run.
Comandos da CLI e apps baseados em arquivo
O .NET 11 Preview 5 também expande o suporte da CLI para aplicações baseadas em arquivo. Agora, os comandos de pacote e de NuGet operam sobre o projeto virtual associado ao arquivo.
Isso significa que adicionar, listar e analisar dependências funciona antes mesmo de converter o arquivo em um projeto convencional:
dotnet package add app.cs System.CommandLine
dotnet package list app.cs
dotnet nuget why app.cs System.CommandLine
O dotnet watch passou a seguir as mesmas regras de seleção de arquivo do dotnet run. Na prática, ele ignora opções como -e e -bl enquanto procura o arquivo de entrada, então um comando como este passa a ser interpretado corretamente:
dotnet watch -e ASPNETCORE_ENVIRONMENT=Development -bl app.cs
Além disso, a CLI agora emite avisos sobre erros comuns.
Por exemplo, imagine passar um .cs para dotnet run dentro de um diretório que já tem um projeto. Nesse caso, o aviso sugere dotnet run --file <file> para um app baseado em arquivo ou dotnet run -- <file> para um argumento.
Aplicações baseadas em arquivo feitas para rodar direto do shell também recebem um aviso de analyzer quando falta o shebang. Com isso, scripts executáveis ficam mais fáceis de acertar na primeira tentativa.
Verificação de vulnerabilidades do SDK no .NET 11 Preview 5
No .NET 11 Preview 5, projetos podem habilitar verificações de vulnerabilidades e de fim de vida do SDK durante o build. O NuGet já avisava sobre pacotes vulneráveis, e agora o mesmo cuidado vale para a versão do SDK em uso.
A habilitação é feita no arquivo de projeto ou no Directory.Build.props:
<PropertyGroup>
<CheckSdkVulnerabilities>true</CheckSdkVulnerabilities>
</PropertyGroup>
Quando ativada, o restore atualiza os metadados de releases do SDK em segundo plano e guarda o cache no diretório .dotnet do usuário. Em seguida, a tarefa de build lê esse cache sem acessar a rede.
Se não houver cache disponível, o build continua normalmente, sem avisos. Portanto, a verificação não deixa a compilação mais lenta nem a torna dependente de internet.
No Preview 5, a funcionalidade usa dois códigos de aviso: NETSDK1236 para vulnerabilidades conhecidas e NETSDK1237 para versões em fim de vida.
warning NETSDK1236: The current .NET SDK (9.0.100) has known vulnerabilities (CVE-2025-12345, CVE-2025-99999). Update to version 9.0.102
warning NETSDK1237: The current .NET SDK (7.0.410) is end of life as of 2024-05-14. It will receive no further security updates
É possível suprimir um código via <NoWarn> sem afetar o outro.
Vale notar que a documentação atual do .NET cita o código NETSDK1239 para o aviso de fim de vida. Por isso, confira o código exato na versão do SDK que você usar.
Template MCP Server no dotnet new
O SDK agora traz embutido o template de projetos MCP Server, sem a necessidade de instalar um pacote de template separado. Antes, era preciso rodar dotnet new install Microsoft.McpServer.ProjectTemplates.
Isso mostra que a Microsoft trata o Model Context Protocol como parte integrante do ecossistema .NET, especialmente em cenários de integração com agentes de IA. Se o protocolo ainda é novidade para você, comece pelo artigo o que é MCP.
dotnet new mcpserver --transport local
O template suporta transportes local e remoto. Segundo a documentação, o local usa stdio e o remoto usa HTTP.
Ele também tem opções para publicação self-contained e para cenários com AOT. Além disso, os testes de integração do SDK já cobrem o template embutido.
O projeto gerado usa o SDK oficial do MCP para C# e já vem com uma ferramenta de exemplo pronta para rodar. Para conhecer essa biblioteca, veja o artigo sobre o lançamento da versão 1 do SDK oficial do MCP para C#.
System.Net.Http.Json por padrão em console apps
Projetos C# que usam Microsoft.NET.Sdk, têm como alvo net11.0 ou superior e habilitam implicit usings passam a receber System.Net.Http.Json automaticamente. Essa mudança alinha projetos de console e de worker aos projetos ASP.NET Core, que já tinham acesso a esse namespace.
using System.Net.Http;
HttpClient client = new();
Todo? todo = await client.GetFromJsonAsync<Todo>("https://example.com/todos/1");
record Todo(int Id, string Title);
Nesse caso, não é mais necessário declarar using System.Net.Http.Json;. O método GetFromJsonAsync fica disponível direto, o que simplifica o código comum de JSON sobre HTTP.
Publicação de containers no .NET 11 Preview 5
O .NET 11 Preview 5 reforça a segurança da publicação de containers embutida no SDK. Agora, o SDK valida o realm retornado pelo desafio de autenticação do registry antes de usá-lo.
A validação exige que o realm seja uma URI absoluta com HTTPS, exceto em registries configurados explicitamente como inseguros. Além disso, o SDK rejeita hosts de realm que resolvem para formas de IP bloqueadas, como loopback, endereços privados, link-local ou não especificados.
O padrão OCI comum, em que o host do registry e o host de autenticação são diferentes, continua funcionando. Por exemplo, um registry pode emitir o desafio de um host e devolver o realm em outro host público com HTTPS.
Em registries privados de desenvolvimento, realms HTTP só valem em um caso. O registry precisa estar configurado como inseguro, e o host do realm deve coincidir com o do registry.
Se você publica imagens sem Dockerfile, o artigo sobre publicar aplicações .NET como containers mostra esse fluxo.
dotnet test em ambientes de IA
O dotnet test agora desabilita as sequências de escape ANSI quando roda via Microsoft.Testing.Platform em um ambiente de LLM. Isso facilita a leitura dos logs por ferramentas que consomem texto simples, como agentes de IA.
O SDK reconhece os mesmos sinais de ambiente LLM usados pela telemetria da CLI. Além disso, a versão adicionou COPILOT_CLI a esse conjunto de detecção.
Em outras palavras, quando um agente executa seus testes, ele recebe um texto limpo, sem códigos de cor misturados ao resultado.
CLI com NativeAOT no .NET 11 Preview 5
O trabalho para transformar a CLI dotnet em uma aplicação NativeAOT avançou no .NET 11 Preview 5.
Primeiro, o Preview 4 criou a base do caminho rápido. Agora, a biblioteca nativa dotnet-aot passou a ser empacotada nos layouts e instaladores do SDK.
O nome do arquivo varia por plataforma: dotnet-aot.dll no Windows, libdotnet-aot.so no Linux e libdotnet-aot.dylib no macOS.
A ativação depende da variável de ambiente DOTNET_CLI_ENABLEAOT=true. Quando ela não está definida, a CLI segue pelo caminho gerenciado tradicional, sem mudar o comportamento padrão.
No Preview 5, nenhum comando é servido integralmente pelo modo AOT. Os previews seguintes ampliariam o conjunto de comandos, incluindo a invocação de ferramentas do SDK pelo caminho AOT.
O objetivo final é uma inicialização quase instantânea para as chamadas mais comuns da CLI. De fato, a documentação do .NET 11 RC 1 já descreve o host NativeAOT habilitado por padrão, com opção de desativar via DOTNET_CLI_ENABLEAOT=false.
Breaking changes do .NET 11 Preview 5
O .NET 11 Preview 5 introduz duas breaking changes que merecem atenção ao atualizar ambientes de build e de CI/CD.
A primeira é a validação mais estrita dos desafios de autenticação em registries de container. Publicações que dependem de realms malformados, de realms sem HTTPS em registries seguros ou de IPs bloqueados passam a falhar mais cedo.
A segunda afeta as diretivas em arquivos incluídos. Diretivas duplicadas, exceto #:project e #:ref, agora geram erro mesmo quando a duplicata vem de um arquivo trazido por #:include.
Ambas seguem o princípio de falhar cedo e de forma explícita. Com isso, o processo de build fica mais seguro e previsível.
Vale observar que as versões seguintes flexibilizaram parte dessa regra. Segundo a documentação do RC 1, diretivas como #:sdk, #:property e #:package podem se repetir entre arquivos incluídos quando têm o mesmo valor.
Correções de bugs no .NET 11 Preview 5
O .NET 11 Preview 5 inclui diversas correções, organizadas por área.
Nas aplicações baseadas em arquivo, os projetos virtuais agora mantêm uma referência forte ao ProjectRootElement. Assim, o garbage collector não quebra mais avaliações posteriores.
Nas ferramentas, dnx e dotnet tool exec passaram a preservar a configuração do NuGet ao executar tools de feeds privados autenticados. Além disso, a leitura da configuração de tools não lança mais NullReferenceException quando falta <RuntimeIdentifierPackages>.
No build e no publish, dotnet publish -o . não exclui mais os arquivos-fonte quando o diretório de publicação é o próprio diretório do projeto. Também foi corrigido o erro na geração do arquivo deps quando o nome do projeto coincide com o de um assembly de referência.
Nos analyzers, a regra CA1033 não é mais reportada para interfaces com implementações padrão. Por fim, na telemetria, o exportador OTLP passou a ficar desabilitado por padrão e pode ser ativado com DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER=true.
Contexto da evolução do SDK do .NET 11
O Preview 5 faz parte de um ciclo cujo lançamento final está previsto para novembro de 2026. Antes dele, os previews anteriores já tinham reduzido o tamanho do instalador do SDK no Linux e no macOS.
Essa redução veio da deduplicação de assemblies por hash de conteúdo, trocando arquivos repetidos por links simbólicos.
No Linux x64, o tarball do SDK caiu de 230 MB para 189 MB em relação ao .NET 10. Ou seja, uma redução de cerca de 17,8%.
A CLI também passou a usar OpenTelemetry com Azure Monitor e exportador OTLP na telemetria opcional. Essa troca substituiu a dependência do Microsoft.ApplicationInsights e deixou a CLI mais compatível com NativeAOT.
Por fim, o dotnet sln ganhou suporte a filtros de solução, permitindo criar e editar arquivos .slnf direto pela CLI. Para ver o panorama completo da versão, confira o artigo sobre o lançamento do .NET 11 Preview 5.
Como testar as novidades
Para experimentar, baixe o SDK do preview na página oficial do .NET 11. Em seguida, crie um arquivo app.cs e rode dotnet run app.cs para testar os apps baseados em arquivo.
Depois, ative a CheckSdkVulnerabilities em um projeto de teste e observe os avisos no build. Também vale gerar um servidor com dotnet new mcpserver e conectá-lo a um cliente MCP, como o GitHub Copilot.
Lembre que um preview não é indicado para produção. No entanto, ele é ideal para avaliar o impacto das mudanças no seu pipeline antes da versão final.
Conclusão
O .NET 11 Preview 5 consolida avanços em três frentes: produtividade, segurança de build e infraestrutura para o futuro da CLI.
O amadurecimento dos apps baseados em arquivo, com referências entre arquivos e diretivas transitivas, reduz a barreira para scripts e prototipação rápida em C#. Enquanto isso, o template MCP Server e o ajuste do dotnet test para ambientes LLM mostram o foco da Microsoft em desenvolvimento orientado a IA.
Por fim, o progresso rumo ao NativeAOT indica que a linha de comando ficará bem mais rápida, sobretudo em automação e CI/CD.
FAQ
O .NET 11 Preview 5 está pronto para produção?
Não. Previews servem para experimentação, testes antecipados e feedback, e a versão final está prevista para novembro de 2026.
Como habilito a verificação de vulnerabilidades do SDK?
Adicione a propriedade CheckSdkVulnerabilities com valor true no arquivo de projeto ou no Directory.Build.props. O restore cuida da atualização dos metadados em segundo plano.
O template MCP Server exige instalar algum pacote?
Não. A partir do Preview 5, o template vem embutido no SDK, e o projeto gerado usa o SDK oficial do MCP para C#.
O caminho NativeAOT da CLI já funciona no Preview 5?
Apenas como opt-in via DOTNET_CLI_ENABLEAOT=true, e nenhum comando é servido inteiramente por ele. A expansão ficou para os previews seguintes.
Por que minha publicação de container passou a falhar?
Provavelmente o registry devolve um realm malformado, sem HTTPS ou apontando para um IP bloqueado. O SDK agora valida esse realm antes de usá-lo.
Preciso declarar using System.Net.Http.Json em console apps?
Não, desde que o projeto use implicit usings e tenha como alvo net11.0 ou superior.