O .NET 11 RC1 pode ser usado em produção com suporte da Microsoft, mas isso não transforma o release candidate em uma versão final nem torna a atualização adequada para todo sistema. A diferença prática do selo go-live é que o RC1 saiu da categoria de preview sem suporte: a Microsoft o considera uma pré-versão suportada em produção. A decisão de adotar agora, porém, continua dependendo de compatibilidade, dependências, capacidade de atualização rápida e tolerância a mudanças antes do GA.
O que “go-live” significa no .NET 11 RC1
O .NET 11 RC1 foi publicado em 8 de setembro de 2026. No anúncio oficial, a equipe do .NET descreve o RC1 como o primeiro de dois release candidates e informa que ele vem com uma licença de suporte go-live para uso em aplicações de produção. A política de suporte da Microsoft define go-live como uma pré-versão, normalmente um RC, que é suportada pela Microsoft em produção.
Há, contudo, uma janela própria: a tabela oficial de suporte lista o .NET 11 RC1 com suporte de 8 de setembro a 13 de outubro de 2026. O lançamento final do .NET 11 está previsto para 10 de novembro de 2026. Portanto, quem coloca o RC1 em produção precisa planejar desde já a migração para a próxima versão suportada e, depois, para o GA.
Fontes oficiais: anúncio do .NET 11 RC1, política de suporte do .NET e calendário de releases do .NET.
Go-live não é sinônimo de “pronto para qualquer produção”
O selo resolve uma questão de suporte do produto, não a análise de risco da sua aplicação. Um RC pode estar suficientemente maduro para workloads reais e ainda receber mudanças antes da versão final. A própria documentação de breaking changes do .NET 11 avisa que a lista ainda está em andamento e pode não estar completa.
Por isso, a pergunta correta não é apenas “a Microsoft suporta?”. É também: o meu sistema, minhas bibliotecas, meu pipeline e minha operação estão preparados para acompanhar um pré-lançamento suportado?
| Cenário | RC1 pode fazer sentido | Melhor esperar |
|---|---|---|
| Aplicação nova ou serviço isolado | Quando há testes fortes, rollback simples e ganho concreto com .NET 11. | Quando não existe necessidade técnica para antecipar a migração. |
| Sistema crítico | Somente com homologação representativa, observabilidade e plano de atualização curto. | Quando mudanças de runtime exigem certificação, janela longa ou alto custo de reversão. |
| Dependências de terceiros | Quando pacotes, agentes, APM, drivers e bibliotecas foram testados com o RC. | Quando o fornecedor ainda não declara compatibilidade ou há componentes fechados difíceis de validar. |
| Ambiente com mudança congelada | Raramente; o RC exige disciplina para acompanhar novas builds. | Quando a organização não consegue atualizar rapidamente após RC2 ou GA. |
Checklist antes de colocar o RC1 em produção
1. Fixe exatamente qual SDK e runtime serão usados
O SDK do .NET é instalado lado a lado, então é possível manter versões anteriores enquanto o RC1 é avaliado. Em repositórios e CI, use global.json para controlar qual SDK é selecionado e evitar que uma máquina com várias versões use silenciosamente outra build. Para versões prévias, também verifique a configuração que permite selecionar prereleases.
A Microsoft documenta o uso de global.json para seleção do SDK. O release oficial do RC1 inclui o SDK 11.0.100-rc.1.26425.128 com runtime 11.0.0-rc.1.26425.128.
2. Faça restore e build limpos com warnings visíveis
Não limite o teste ao fato de a solução compilar. Rode restore em ambiente limpo, recompile tudo e investigue warnings novos de compilador, SDK, analisadores, source generators, MSBuild e NuGet. Projetos que usam tarefas customizadas de build ou ferramentas que inspecionam internals do SDK merecem atenção especial.
3. Revise breaking changes antes de culpar “um bug do RC”
O .NET 11 traz mudanças que podem ser binárias, de código-fonte ou comportamentais. Isso significa que um binário existente pode se comportar de modo diferente, um projeto pode exigir alteração para recompilar ou uma API pode manter a compilação e mudar o comportamento em runtime. Use a lista oficial de breaking changes do .NET 11 como roteiro, lembrando que a própria página é marcada como trabalho em andamento.
4. Valide bibliotecas, workloads e ferramentas fora do runtime
O suporte go-live do .NET não é uma garantia automática de compatibilidade para cada pacote de terceiros, extensão, agente de observabilidade, driver, ORM adicional, workload móvel ou ferramenta de build. Confirme versões suportadas, rode testes de integração e verifique se há dependências que ainda bloqueiam net11.0 ou SDKs prerelease.
No Windows, o anúncio recomenda o Visual Studio 2026 Insiders; outra opção indicada é Visual Studio Code com C# Dev Kit. O objetivo é manter o ambiente de desenvolvimento alinhado à toolchain que efetivamente conhece o RC1.
5. Teste comportamento, não só compilação
Priorize fluxos de negócio, serialização, autenticação, criptografia, rede, acesso a dados, filas, jobs, interoperabilidade nativa e qualquer caminho sensível a runtime ou JIT. Depois, compare latência, throughput, alocação de memória, consumo de CPU, tempo de startup e padrões de GC com a versão atualmente usada em produção. Uma regressão pequena em benchmark sintético pode não importar; uma regressão em uma rota crítica pode impedir a adoção.
6. Reproduza o deployment real
Teste o mesmo modelo que será publicado: framework-dependent, self-contained, container, IIS, serviço Linux ou outro formato. Isso importa porque a responsabilidade de atualização muda. Em aplicações framework-dependent, o runtime instalado no host pode ser atualizado pelo mecanismo de servicing aplicável. Em deployments self-contained, a aplicação leva seu próprio runtime, então a equipe precisa reconstruir e republicar para incorporar uma versão nova.
Para containers, evite tratar uma tag mutável como evidência de reprodutibilidade. Registre a imagem efetivamente promovida e tenha um processo claro para reconstruir quando chegar RC2, uma correção de segurança ou o GA.
7. Garanta rollback e observabilidade antes do primeiro tráfego
Um deployment antecipado só é racional se houver como detectar regressões e voltar rapidamente. Defina métricas, logs, traces, alertas e critérios de abortar a promoção. Se houver mudança de schema de banco, protocolo, fila ou formato persistido, valide se o rollback da aplicação continua possível depois da migração.
8. Ensaie a próxima atualização agora
O RC1 não deve ser tratado como um destino de longo prazo. Como o suporte dessa build termina em 13 de outubro de 2026, faça um ensaio de atualização em homologação antes de colocar o RC1 em produção: troca do SDK, rebuild, testes e rollout. Isso reduz o risco de descobrir tarde que a organização consegue adotar o RC1, mas não consegue sair dele rapidamente.
Quais novidades do RC1 merecem atenção nos testes
O anúncio do RC1 reúne mudanças em bibliotecas, runtime, SDK, MSBuild, NuGet, C# 15, F#, ASP.NET Core, .NET MAUI e Windows Forms. Entre os destaques estão melhorias no dotnet test, publicação de containers mais reprodutível, mudanças de autenticação no SignalR, recursos de C# 15 estabilizados e ajustes de runtime. Isso não significa que todo projeto precise testar todas as áreas: concentre-se nas partes que realmente entram no seu stack.
As release notes completas do .NET 11 RC1 são a referência mais útil para montar uma matriz de testes por componente.
RC1 agora ou versão final: um critério simples de decisão
Adotar o RC1 é mais defensável quando há benefício concreto, cobertura de testes confiável, dependências verificadas, deployment reproduzível e capacidade de atualizar em poucas semanas. É menos defensável quando a única motivação é “estar na versão mais nova”, principalmente em ambientes com processo de mudança lento ou fornecedores que ainda não suportam a nova linha.
Também vale considerar o ciclo de vida: o .NET 11 é uma versão STS, não LTS. Para equipes que preferem ciclos mais longos e menos upgrades de versão principal, isso pesa na estratégia mesmo depois do GA.
O que registrar antes de aprovar a adoção
- versão exata do SDK, runtime e imagens de container usadas;
- resultado de restore, build, testes unitários, integração e end-to-end;
- breaking changes revisados e impacto documentado;
- status de compatibilidade dos pacotes e ferramentas críticas;
- comparativo de performance e consumo de recursos;
- plano de rollback testado;
- responsável e prazo para migrar do RC1 para a próxima build suportada;
- data de reavaliação antes do fim de suporte do RC1.
Em resumo, o go-live do .NET 11 RC1 abre a porta para produção com suporte oficial; ele não elimina a necessidade de engenharia de risco. Se sua equipe consegue provar compatibilidade e manter uma cadência rápida de atualização, o RC1 pode ser uma etapa útil de adoção antecipada. Se não consegue, esperar o GA é uma decisão técnica perfeitamente coerente.
