.NET 11 RC 2: novidades nas bibliotecas

O que é o .NET 11 RC 2 e por que ele importa

Um release candidate é uma versão praticamente fechada, em que o time do .NET concentra esforços em estabilidade e em pequenos ajustes de API. Por isso, o .NET 11 RC 2 representa o retrato mais fiel do que chegará na versão final.

A Microsoft prevê o lançamento oficial do .NET 11 para novembro de 2026. Até lá, as mudanças tendem a ser pontuais, e as notas de cada RC indicam com clareza o que ainda se move.

Além disso, o .NET 11 é uma versão de suporte padrão (STS), e não uma versão LTS. Na prática, isso significa um ciclo de suporte menor, então vale planejar a atualização com calma.

Neste RC, as novidades das bibliotecas se concentram em quatro frentes:

• Leitura de CBOR em blocos, sem copiar o documento inteiro para a memória.
• Novas APIs experimentais de criptografia pós-quântica e híbrida.
• Formatação de mensagens de validação com argumentos próprios de cada atributo.
• Controle da concorrência inicial em conexões HTTP/2.

Também há uma breaking change no iOS e no tvOS, ajustes em relação ao RC 1 e algumas correções de bugs. A seguir, você vê cada ponto em detalhes.

Leitura incremental de CBOR no .NET 11 RC 2

O CBOR (Concise Binary Object Representation) é um formato binário compacto, inspirado no JSON, muito usado em IoT, WebAuthn e protocolos de segurança. O namespace System.Formats.Cbor já oferecia o CborReader, mas ele exigia o documento completo em memória contígua.

Com o .NET 11 RC 2, o CborReader passa a ler um payload que chega em pedaços. Dessa forma, você processa dados vindos de rede ou de arquivo sem montar um buffer gigante antes.

using System.Formats.Cbor;

// Primeiro bloco: início de um array com dois itens e o valor 10
ReadOnlyMemory<byte> firstChunk = new byte[] { 0x82, 0x0a };

// Segundo bloco: o valor 20
ReadOnlyMemory<byte> nextChunk = new byte[] { 0x14 };

var reader = new CborReader(
    firstChunk,
    new CborReaderOptions { ConformanceMode = CborConformanceMode.Lax },
    isFinalBlock: false);

reader.ReadStartArray();
int first = reader.ReadInt32(); // 10

if (reader.PeekState() == CborReaderState.NeedsMoreData)
{
    // Só desliza os dados quando o bloco atual foi consumido por completo
    if (reader.BytesRemaining == 0)
        reader.SlideData(nextChunk, isFinalBlock: true);
    else
        throw new InvalidOperationException("Buffer management omitted from the sample.");
}

int second = reader.ReadInt32(); // 20
reader.ReadEndArray();

Criptografia pós-quântica no .NET 11 RC 2

A criptografia pós-quântica (PQC) busca proteger dados contra computadores quânticos capazes de quebrar algoritmos clássicos como RSA e curvas elípticas. O .NET 10 já trouxe o ML-KEM, e o .NET 11 RC 2 avança nesse caminho com duas APIs experimentais.

<PropertyGroup>
  <!-- Consentimento explícito para APIs experimentais de criptografia -->
  <NoWarn>$(NoWarn);SYSLIB5006;SYSLIB5009</NoWarn>
</PropertyGroup>

Mensagens de validação com FormatMessage

O namespace System.ComponentModel.DataAnnotations ganhou o método ValidationAttribute.FormatMessage. Com ele, o host de validação fornece um template de mensagem, enquanto o próprio atributo preenche os seus placeholders.

Na prática, isso resolve um problema antigo de localização. Antes, quem queria traduzir a mensagem do RangeAttribute precisava duplicar a lógica de formatação para inserir os valores mínimo e máximo.

using System.ComponentModel.DataAnnotations;

var range = new RangeAttribute(1, 10);

// O host fornece o template e o atributo preenche {1} e {2}
string message = range.FormatMessage(
    "{0} must be between {1} and {2}",
    "Quantity");

Console.WriteLine(message); // Quantity must be between 1 and 10

O primeiro argumento é o template, que normalmente viria de um arquivo de recursos. Já o segundo argumento é o nome do campo, que ocupa o placeholder {0}.

Dessa forma, frameworks de validação e bibliotecas de localização conseguem reaproveitar o comportamento dos atributos nativos. Se você trabalha com APIs que devolvem erros padronizados, essa novidade combina bem com uma estratégia de tratamento global de exceções com IExceptionHandler.

Concorrência inicial do HTTP/2 no .NET 11 RC 2

No HTTP/2, várias requisições compartilham a mesma conexão por meio de streams. O servidor informa quantos streams simultâneos aceita no frame SETTINGS, mas esse frame só chega depois que a conexão já foi aberta.

Enquanto o SETTINGS não chega, o cliente do .NET assume um limite padrão de 100 streams. Se o servidor aceitar menos que isso, o cliente pode disparar uma rajada inicial maior do que o servidor suporta.

Por isso, o .NET 11 RC 2 adiciona a propriedade SocketsHttpHandler.InitialHttp2MaxConcurrentStreams. Ela limita os streams concorrentes em cada nova conexão HTTP/2 até a chegada do frame SETTINGS.

using System.Net;

var handler = new SocketsHttpHandler
{
    // Limite usado apenas até o servidor anunciar o seu próprio valor
    InitialHttp2MaxConcurrentStreams = 20
};

using var client = new HttpClient(handler)
{
    DefaultRequestVersion = HttpVersion.Version20,
    DefaultVersionPolicy = HttpVersionPolicy.RequestVersionOrHigher
};

var response = await client.GetAsync("https://api.example.com/orders");

Depois que o SETTINGS chega, a conexão passa a respeitar o limite anunciado pelo servidor. Em outras palavras, a propriedade afeta apenas o começo da vida de cada conexão.

O valor mínimo aceito é 1. Além disso, se uma conexão anterior com o mesmo host já recebeu um limite menor, o handler pode reduzir ainda mais a concorrência inicial.

Use essa configuração quando você conhece o limite do servidor e sabe que ele fica abaixo de 100. Gateways, proxies reversos e serviços legados costumam ser bons candidatos.

Breaking change de travas de arquivo no iOS e tvOS

O RC 2 desativa por padrão o advisory file locking no iOS e no tvOS. O motivo é evitar que o sistema operacional encerre o app quando ele vai para segundo plano segurando uma trava de arquivo.

Como consequência, as restrições de FileShare deixam de valer nesses sistemas. Isso inclui handles abertos dentro do mesmo processo, então dois trechos do seu código podem abrir o mesmo arquivo sem conflito.

O Mac Catalyst e as demais plataformas mantêm o comportamento anterior. Caso o seu app dependa das travas, restaure o comportamento com a propriedade de runtime System.IO.DisableFileLocking:

{
  "configProperties": {
    "System.IO.DisableFileLocking": false
  }
}

Outra opção é definir a variável de ambiente DOTNET_SYSTEM_IO_DISABLEFILELOCKING com o valor 0. No entanto, ao reativar as travas, você também traz de volta o risco de encerramento do app durante a suspensão.

O que mudou desde o RC 1

Além das APIs novas, o RC 2 ajusta recursos que já existiam no RC 1. Essas mudanças são pequenas, mas podem quebrar dashboards e testes automatizados.

Correções de bugs no .NET 11 RC 2

O .NET 11 RC 2 também corrige problemas em duas bibliotecas muito usadas. No System.Collections.Concurrent, o ConcurrentQueue não informa mais que está vazio durante o crescimento de segmentos ao chamar TryDequeue ou TryPeek.

Já no System.Text.Json, as correções se concentram nos novos union types do C# e na serialização polimórfica:

• O serializador agora infere tipos derivados em hierarquias fechadas aninhadas.
• Em unions do C#, o JsonNumberHandlingAttribute passa a valer.
• Unions com conversores customizados não disparam mais o aviso SYSLIB1227.
• Os unsafe accessors gerados ficam compatíveis com a nova semântica de unsafe do C#.

Embora pareçam detalhes, essas correções afetam código concorrente e APIs que serializam unions. Assim, vale rodar sua suíte de testes contra o RC 2 se você já experimenta esses recursos.

Quem deve prestar atenção nestas mudanças

Nem toda novidade afeta todos os projetos da mesma forma. Por isso, vale separar o impacto do .NET 11 RC 2 por perfil de aplicação.

Times de IoT e de autenticação com WebAuthn ganham mais com a leitura incremental de CBOR. Afinal, esses cenários costumam receber payloads binários pela rede, em pedaços e com memória limitada.

Por outro lado, quem cuida de segurança e conformidade deve olhar com carinho para CompositeMLKem, Hpke e o EnvelopedCms com ML-KEM. Mesmo experimentais, essas APIs permitem montar provas de conceito e medir o custo da migração pós-quântica desde já.

Já os times que mantêm APIs com validação e mensagens traduzidas se beneficiam do FormatMessage. Com ele, o código de localização fica menor e deixa de copiar a lógica interna de cada atributo.

Serviços que consomem muitas APIs HTTP/2 de terceiros encontram no InitialHttp2MaxConcurrentStreams uma forma simples de evitar rejeições de streams logo após abrir a conexão. Isso é especialmente útil em clientes de alto volume, como workers e gateways.

Finalmente, desenvolvedores mobile com .NET MAUI precisam revisar a breaking change de travas de arquivo. Um app que confiava no FileShare para proteger um banco local, por exemplo, pode passar a sofrer acessos concorrentes inesperados.

Em resumo, mesmo quem não usa nenhuma API nova ainda precisa olhar as métricas do MemoryCache e os tipos decimais. Essas mudanças silenciosas são justamente as que mais surpreendem depois da atualização.

Como testar o .NET 11 RC 2 no seu projeto

O caminho mais seguro é criar um branch e apontar o projeto para o novo target framework. Primeiro, instale o SDK do .NET 11 RC 2 e confira a versão:

dotnet --list-sdks
dotnet new console -n RcPlayground -f net11.0

Em seguida, ajuste o TargetFramework dos projetos existentes para net11.0 e rode a suíte de testes. Dessa forma, você descobre cedo as breaking changes que afetam o seu código.

Depois, revise três pontos específicos deste RC:

1. Filtros de telemetria que usam dotnet.cache.request.type.
2. Apps iOS e tvOS que dependem de FileShare para evitar acesso concorrente.
3. Testes que comparam resultados de Decimal128 com valores salvos.

Se o seu time acompanha as novidades do .NET 11 de perto, também vale conferir como o StringBuilder.MoveChunks evita alocações e como funcionam os Blazor AI components. Para a lista completa de mudanças, consulte as notas de versão das bibliotecas no GitHub.

Conclusão sobre o .NET 11 RC 2

O .NET 11 RC 2 não traz grandes revoluções, mas entrega APIs que resolvem dores bem concretas. A leitura incremental de CBOR reduz o uso de memória, e o FormatMessage simplifica a localização de mensagens de validação.

Na criptografia, CompositeMLKem e Hpke mostram que a plataforma leva a sério a transição pós-quântica. Ainda assim, por serem experimentais, essas APIs merecem testes em ambientes controlados antes de chegar à produção.

Por fim, a propriedade InitialHttp2MaxConcurrentStreams dá controle fino sobre o início das conexões HTTP/2. Junto com a breaking change no iOS e no tvOS e os ajustes do RC 1, ela compõe um pacote que vale testar agora, antes da versão final de novembro.

FAQ

O .NET 11 RC 2 já pode ser usado em produção?

Um release candidate é uma versão quase final, mas ainda pode receber ajustes. Por isso, avalie o risco do seu cenário e prefira validar em ambientes de homologação antes da versão final.

O .NET 11 é uma versão LTS?

Não, o .NET 11 é uma versão de suporte padrão (STS). A versão LTS mais recente continua sendo o .NET 10.

Por que a leitura incremental de CBOR exige o modo Lax?

Os modos estritos validam o documento completo, o que não é possível com blocos parciais. Assim, apenas o modo Lax aceita blocos que não são o final.

Como habilitar as APIs experimentais de criptografia?

Suprima os diagnósticos SYSLIB5006 e SYSLIB5009 na propriedade NoWarn do projeto. Cada ID libera apenas a API correspondente.

A propriedade InitialHttp2MaxConcurrentStreams substitui o limite do servidor?

Não, ela vale apenas até a chegada do frame SETTINGS. Depois disso, a conexão passa a usar o limite anunciado pelo servidor.