.NET 11 RC 1: Novidades, C# 15 padrão e go-live
O .NET 11 RC 1 chegou em 8 de setembro de 2026 como o primeiro release candidate da versão e, diferente das previews, traz uma go-live license com suporte oficial da Microsoft para uso em produção. Neste artigo, você entende o que muda em bibliotecas, runtime, SDK, C#, ASP.NET Core e breaking changes, com atenção ao que exige ação na migração.
Esse detalhe muda a natureza da conversa. Até a Preview 7, avaliar a nova versão era curiosidade técnica, enquanto a partir daqui passa a ser uma decisão de planejamento.
Por que o .NET 11 RC 1 é diferente das previews
Um release candidate não é apenas mais uma preview numerada. Na verdade, ele marca o congelamento da superfície pública de API e o fim do ciclo de renomeações.
Por isso, boa parte do conteúdo do .NET 11 RC 1 consiste em finalizar nomes de tipos e propriedades que circularam instáveis nas previews. Quem acompanhou o ciclo desde a Preview 6 encontra aqui um roteiro de renomeações a aplicar.
Essa característica define a estratégia de adoção. Afinal, código escrito contra a Preview 7 provavelmente não compila neste release sem ajustes, e isso é esperado.
Para avaliar a build, você pode usar o Visual Studio 2026 Insiders ou o Visual Studio Code com o C# Dev Kit. Além disso, o SDK fica disponível no instalador oficial do .NET 11.
Se você acompanhou a série desde o começo, vale revisitar as novidades do runtime no .NET 11 Preview 1. Assim, fica mais fácil entender de onde parte o trabalho que agora se consolida.
Bibliotecas no .NET 11 RC 1: processos, rede e JSON
A camada de bibliotecas concentra o maior volume de novidades desta build. O ponto mais visível, contudo, é a sinalização de processos direto na classe Process.
Até então, enviar um sinal POSIX exigia trabalhar com SafeProcessHandle. Agora, o método Signal envia o sinal diretamente, e os métodos de espera retornam um ProcessExitStatus, que distingue uma saída normal de uma terminação por sinal.
using System.Diagnostics;
using System.Runtime.InteropServices;
// Inicia um processo e pede o encerramento com SIGTERM
using Process process = Process.Start("sleep", "30")!;
process.Signal(PosixSignal.SIGTERM);
// O status informa se o processo saiu normalmente ou por sinal
ProcessExitStatus status = await process.WaitForExitStatusAsync();
Para quem escreve orquestradores, supervisores ou ferramentas de linha de comando em Linux e macOS, essa API elimina uma camada de interop manual. Na prática, ela continua o trabalho iniciado na expansão da API de Process no .NET 11 Preview 4.
TLS dirigido pelo chamador e DNS no Linux
O System.Net.Security ganhou uma máquina de estados TLS dirigida pelo chamador, com os tipos TlsContext, TlsSession, TlsBufferSession e TlsSocketSession. Todas essas APIs são experimentais no .NET 11 e emitem o diagnóstico SYSLIB5007.
A proposta atende transportes avançados, nos quais a aplicação controla os buffers e o agendamento de I/O. Assim, handshake, leitura, escrita e shutdown retornam um TlsOperationStatus, que indica conclusão, necessidade de mais entrada ou validação de certificado.
Além disso, as APIs de resolução de registros DNS da Preview 7 ganharam implementação em Linux. Então, DnsResolver e os métodos Dns.Resolve* resolvem registros de endereço, SRV, MX, TXT, CNAME, PTR e NS, em vez de lançar PlatformNotSupportedException.
System.Text.Json e as unions
O System.Text.Json recebeu conversores nativos para BFloat16, Decimal32, Decimal64 e Decimal128. Eles funcionam tanto com reflexão quanto com source generator.
O JsonSchemaExporter também passou a identificar a representação base64 de byte[], Memory<byte> e ReadOnlyMemory<byte>. Com isso, o schema gerado emite contentEncoding para esses tipos.
Do ponto de vista arquitetural, porém, o destaque é o JsonUnionTypeStructuralClassifier. Esse novo ponto de extensão classifica union types do C# de forma estrutural e fecha a infraestrutura para o suporte completo a unions no serializador.
Com ele, uma union cujos casos têm formato de objeto pode ser desserializada pelos nomes de propriedade que distinguem cada caso. Ou seja, o JSON dispensa um discriminador explícito.
using System.Text.Json.Serialization;
// O classificador estrutural escolhe o caso pelas propriedades do JSON
[JsonUnion(TypeClassifier = typeof(JsonUnionTypeStructuralClassifier))]
public union PetUnion(Dog, Cat);
Complementando esse cenário, o atributo JsonPolymorphicAttribute.InferClosedTypePolymorphism permite que uma hierarquia fechada opte pela inferência de tipos derivados. Dessa forma, autores de biblioteca ganham controle local, sem depender de uma configuração global no JsonSerializerOptions.
Quem quiser o histórico dessa evolução encontra o ponto de partida nas novidades das bibliotecas base do .NET 11 Preview 1.
Validação, coleções, compressão e criptografia
Os validadores de options gerados por source generator agora fornecem também a implementação síncrona de IValidateOptions<TOptions>. Além disso, a interface IStartupValidator ficou obsoleta em favor de IAsyncStartupValidator.
O BitArray passou a aceitar ReadOnlySpan<bool>, ReadOnlySpan<byte> e ReadOnlySpan<int> nos construtores. Em Windows Arm64, os benchmarks mostraram ganhos de 33% a 51% sobre span.ToArray(), com cerca de 50% menos alocações para bytes e inteiros.
Os encoders e decoders sem stream de Deflate, ZLib e GZip receberam um método Reset(). Assim, uma instância volta ao estado inicial e processa outra carga sem nova alocação.
No campo criptográfico, a classe Aes passou a suportar AES Key Wrap sem padding, definido pela RFC 3394, com EncryptKeyWrap, DecryptKeyWrap, TryDecryptKeyWrap e GetKeyWrapLength. Já em plataformas Apple, AesGcm e ChaCha20Poly1305 deixaram de passar dados associados vazios ao CryptoKit, o que libera o caminho rápido nativo.
Runtime no .NET 11 RC 1: crash report e FP16
O relatório de falhas em processo chegou ao Linux e ao macOS. Quando DOTNET_DbgEnableMiniDump não está ativo, definir DOTNET_EnableCrashReport=1 seleciona o reporter in-process.
A segunda mudança do runtime no .NET 11 RC 1 é silenciosa e não exige código novo. O JIT passou a emitir instruções FP16 de hardware para aritmética e conversões de System.Half quando o processador oferece suporte.
Em x64, a aritmética usa AVX10.1, enquanto conversões entre Half e float podem usar F16C. Em Arm64, por sua vez, a aritmética recorre ao conjunto opcional de instruções FP16.
A representação ABI de Half continua igual, o que torna a otimização transparente. Portanto, cargas de inferência e processamento de sinais em meia precisão devem ganhar desempenho sem intervenção.
SDK no .NET 11 RC 1: testes, containers e formatação
O caminho do Microsoft.Testing.Platform no dotnet test passou a suportar projetos de teste para Android, iOS, macOS e Mac Catalyst. Para Android e iOS, o comando seleciona dispositivos conectados, emuladores ou simuladores.
Os workloads incluem templates dedicados, como dotnet new androidtest, dotnet new iostest, dotnet new macostest e dotnet new maccatalysttest. O MSTest vem como padrão, mas qualquer framework suportado pela plataforma de testes funciona.
O comando também ganhou opções de escopo de execução, que valem para o run completo. Nesse caso, você posiciona essas opções antes do separador --:
# Encerra toda a execução de testes após 90 segundos
dotnet test --timeout 90s
# Interrompe a execução quando cinco testes falharem
dotnet test --maximum-failed-tests 5
Um timeout retorna o código de saída 3, enquanto --maximum-failed-tests retorna 13. Para execuções multi-target, a opção --results-directory-layout per-module isola a saída de cada aplicação de teste.
A publicação de containers também melhorou no .NET 11 RC 1. Com SOURCE_DATE_EPOCH definido com um timestamp estável, publicações independentes das mesmas entradas produzem o mesmo digest de imagem.
Além disso, publicações em registries remotos verificam se o manifesto calculado já existe no destino. Quando existe, o SDK pula layers e configuração e apenas aplica as tags pedidas.
Os programas baseados em arquivo continuam evoluindo. O caminho de Native AOT reaproveita saídas de build quando o programa não mudou, e o dotnet format já aceita um arquivo .cs isolado.
No formatador, o modo de pasta passou a buscar arquivos .editorconfig apenas nos diretórios ancestrais dos arquivos formatados. Em um benchmark de monorepo, formatar um único arquivo caiu de 1,09 segundo para 0,55 segundo.
MSBuild, NuGet, MAUI e Windows Forms
As mudanças nessas áreas são pontuais, mas úteis no dia a dia. O MSBuild ganhou tarefas para criar e extrair arquivos tar e passou a expor os padrões glob de itens para ferramentas de build.
No NuGet, o pack reaproveita avaliações de projeto já feitas. Também a atualização de pacotes vulneráveis passou a funcionar em projetos que tratam avisos como erros.
Segundo o anúncio oficial, o .NET MAUI recebeu melhorias de testes, recursos de plataforma e XAML. Já o Windows Forms traz gerenciamento de modo quiosque e a estabilização dos estilos visuais modernos.
C# 15 vira padrão no .NET 11 RC 1
Esta é a mudança de maior impacto simbólico da build. A partir do .NET 11 RC 1, o C# 15 passa a ser a versão padrão em projetos que têm o .NET 11 como target.
Com isso, os recursos que amadureceram nas previews saem da condição experimental. A lista inclui argumentos em expressões de coleção, union types, membros estáticos de interface não virtuais, hierarquias fechadas, break e continue rotulados e indexadores de extensão.
Union types sem LangVersion preview
Os union types deixam de exigir <LangVersion>preview</LangVersion> no arquivo de projeto. Para se aprofundar no recurso, veja o artigo sobre union types no .NET 11.
public union Result(Success, Failure);
// O compilador exige que o switch trate todos os casos da union
static string Describe(Result result) => result switch
{
Success(var message) => message,
Failure(var errorCode) => $"Error {errorCode}"
};
O compilador verifica exaustividade nas expressões switch sobre uma union. Então, adicionar um novo caso gera erro de compilação em todos os pontos de consumo.
Essa é a garantia que faltava para modelar resultados e comandos sem interfaces marcadoras. Além disso, as APIs do Roslyn adotaram os nomes finais de versão de linguagem, e ITypeSymbol.UnionCaseTypes expõe os casos de uma union para analisadores.
Unsafe Evolution e F#
O trabalho de Unsafe Evolution segue independente do C# 15 e ainda exige linguagem em preview com a flag updated-memory-safety-rules. Mesmo assim, o .NET 11 RC 1 finalizou várias regras.
Por exemplo, await agora funciona dentro de um contexto unsafe. Por outro lado, o modificador unsafe em delegates, construtores estáticos, destrutores e declarações de tipo virou erro, porque não estabelece mais um contexto significativo.
No F#, o destaque fica com record spreads, construtores de record e construção direta de delegates. Também entram strings interpoladas eficientes e formatação de records e unions sem reflexão.
ASP.NET Core no .NET 11 RC 1: autenticação e nomes finais
O eixo central do ASP.NET Core neste release é renovar a autenticação sem derrubar conexões. As APIs de authentication refresh do SignalR, introduzidas na Preview 6, tiveram seus formatos finalizados no servidor e no cliente .NET.
Quem vem da Preview 7 precisa mover os callbacks OnAuthenticationRefreshed e OnAuthenticationRefreshFailed de AuthenticationRefreshOptions para eventos em HubConnection. Também precisa trocar Microsoft.AspNetCore.Http.Connections.AuthenticationRefreshContext por Microsoft.AspNetCore.Connections.Features.AuthenticationRefreshContext.
O cliente TypeScript ganhou capacidade equivalente, com withAuthenticationRefresh e handlers de sucesso e falha. No Blazor Server, por sua vez, circuitos interativos recebem o ClaimsPrincipal renovado sem reconectar.
Nesse fluxo, o hub de componentes habilita o refresh automaticamente e dispara AuthenticationStateChanged. Assim, componentes como AuthorizeView renderizam de novo com a identidade atualizada.
O acúmulo de melhorias no Blazor começou bem antes, como mostram as novidades do ASP.NET no .NET 11 Preview 5.
OpenAPI, validação e opções do Blazor
A geração de OpenAPI passou a mapear [Obsolete] para deprecated: true em operações, tipos e propriedades de schema. Com isso, clientes gerados enxergam a mesma depreciação que os chamadores em .NET.
A localização de mensagens de validação abandonou a API MessageKeyProvider, exclusiva de preview, em favor de convenções de nome de recurso. A busca tenta três chaves, começando por {DeclaringType}_{MemberName}_{AttributeType}_Error.
As opções de browser do Blazor também receberam nomes definitivos. Agora, BrowserOptions.Server vira BrowserOptions.InteractiveServer, BrowserOptions.Ssr vira BrowserOptions.StaticServer e BrowserOptions.WebAssembly vira BrowserOptions.InteractiveWebAssembly.
Kestrel e Device Bound Session Credentials
A autenticação Negotiate no Kestrel passou a usar o token de channel binding do endpoint TLS em conexões HTTPS, sem configuração extra. Essa mudança se apoia no suporte a channel binding em Unix da camada de bibliotecas.
Por fim, chegou uma implementação experimental de Device Bound Session Credentials, no pacote Microsoft.AspNetCore.Authentication.DeviceBoundSessions. A especificação vincula a renovação da sessão a uma chave privada do navegador, de modo que um cookie copiado não estende a sessão sem essa chave.
Breaking changes do .NET 11 RC 1
Algumas mudanças merecem leitura cuidadosa antes de qualquer upgrade. A mais delicada, de fato, é numérica.
Conversões entre decimal e ponto flutuante binário, assim como de BigInteger para tipos binários, agora arredondam o valor exato uma única vez para o representável mais próximo. Além disso, não existe switch de compatibilidade para o algoritmo antigo.
Por isso, testes e valores serializados que dependiam do resultado antigo precisam de revisão. A recomendação oficial é usar literais decimais quando a intenção for decimal.
As métricas HTTP open_connections e active_requests viraram instrumentos observáveis. Então, código que usa MeterListener diretamente precisa chamar RecordObservableInstruments para continuar recebendo medições.
No SDK, a variável de ambiente Configuration passou a definir o valor padrão de --configuration e -c. Assim, scripts que definem essa variável podem selecionar uma configuração diferente da anterior.
No ASP.NET Core, a UI padrão do Identity passou a honrar todos os requisitos de confirmação após o registro. Ou seja, usuários que exigem e-mail, telefone ou conta confirmados vão para a confirmação em vez de entrar automaticamente.
O switch Microsoft.AspNetCore.Server.Kestrel.InsecureChunkedParsing deixou de existir, sem substituto. Também projetos com IdentityUIFrameworkVersion igual a Bootstrap4 passam a receber aviso de MSBuild.
A lista completa fica nas notas de lançamento do .NET 11 RC 1. Vale lê-las antes de abrir a branch de migração.
Como adotar o .NET 11 RC 1
Para times que acompanharam as previews, o trabalho imediato é aplicar as renomeações. Na prática, SignalR, opções de browser do Blazor e localização de validação concentram quase toda essa dívida.
Para quem ainda não olhou a versão, este é o momento de começar. Afinal, a go-live license do .NET 11 RC 1 remove o principal argumento contra a experimentação séria, e a superfície de API não deve mudar até a versão final.
A abordagem prática envolve subir uma branch de avaliação, atualizar o SDK, compilar e catalogar os erros. A maioria será mecânica, porém a mudança de arredondamento numérico não quebra a compilação, e sim o resultado.
Conclusão
O .NET 11 RC 1 tem um perfil claro: pouca novidade conceitual e muita consolidação. O grande marco é o C# 15 como versão padrão, que tira as unions da zona experimental e as torna uma ferramenta legítima de modelagem.
Além disso, a go-live license transforma a avaliação em planejamento concreto. Com testes de regressão numérica e as renomeações aplicadas, o caminho até a versão final de novembro fica bem mais curto.
FAQ
O .NET 11 RC 1 pode ser usado em produção?
Sim, porque a build vem com go-live license e suporte oficial da Microsoft. Ainda assim, avalie em ambiente controlado antes de promover.
Preciso mudar o arquivo de projeto para usar union types?
Não. A partir do RC 1, o C# 15 é a versão padrão para projetos com target .NET 11, e as unions deixam de exigir LangVersion em preview.
Código escrito contra a Preview 7 compila no RC 1?
Provavelmente não sem ajustes, se usar authentication refresh do SignalR, opções de browser do Blazor ou localização de validação. O RC 1 finalizou os nomes dessas APIs.
A mudança de arredondamento numérico afeta binários já compilados?
Sim. Tanto binários existentes quanto código recompilado podem produzir resultados diferentes, e não há switch de compatibilidade.
O suporte a DBSC já pode ir para produção?
Não, porque o pacote é experimental e segue em prerelease durante o ciclo do .NET 11. O suporte no navegador também depende de implementação experimental.
Qual IDE usar para avaliar a versão?
O Visual Studio 2026 Insiders é a opção indicada no Windows. Em qualquer plataforma, o Visual Studio Code com o C# Dev Kit também funciona.
As otimizações de FP16 exigem configuração?
Não. O JIT emite as instruções de hardware quando o processador oferece suporte, e a ABI de Half continua igual.