Migre do .NET Framework 4.8 para o .NET 11 em 2026

Correção — 2 de novembro de 2026: Foram corrigidos status/suporte do .NET 11, ciclo de vida do Framework, configuração, serialização, ferramentas e implantação. Foram removidas estimativas sem evidência de duração, economia de memória e experiências supostamente realizadas.

Migrar do .NET Framework 4.8 para .NET moderno pode exigir outro host e mudanças nas bibliotecas, implantação e contratos de dados. Não é uma atualização de runtime no lugar. Identifique primeiro o motivo e qual parte pode migrar independentemente.

Nesta revisão, .NET 11 RC3 é um pré-lançamento go-live, .NET 11 é uma linha STS e .NET 10 é a opção LTS lançada. O suporte do Framework acompanha o produto Windows; não existe uma única data final do Framework 4.8 para todas as instalações Windows 10. Confira o SO real e sua versão suportada do Framework.

Inventarie antes de alterar projetos

Compile e teste a aplicação existente no ambiente Windows suportado. Mantenha developer/reference packs e ferramentas disponíveis durante a migração. Registre autenticação, sessões, integrações Windows, bibliotecas nativas, jobs, providers e formatos persistidos. Compatibilidade depende de APIs e assets, não de uma regra que invalida toda biblioteca net48.

A visão geral do Upgrade Assistant agora marca a ferramenta como obsoleta e aponta para o agente de modernização do GitHub Copilot. Automação é opcional; revise e teste suas alterações. Um comando antigo sem versão fixada não garante suporte ao .NET 11.

Separe a limpeza do formato do projeto da migração do runtime quando possível. SDK-style não traduz System.Web, hosting WCF, COM ou tarefas MSBuild personalizadas. Preserve uma referência funcional e migre bibliotecas folha antes dos consumidores.

Escolha a fronteira da migração

O guia ASP.NET admite migração incremental. Rotas atrás de proxy permitem manter o legado funcionando. Migração parcial é válida quando autenticação, roteamento, propriedade dos dados e rollback são deliberadamente gerenciados.

CoreWCF não garante igualdade de todos os recursos e contratos WCF. Teste os bindings e a autenticação usados. EF6 suporta .NET moderno desde 6.3; escolha e teste uma versão/provider atual compatível em vez de tratar 6.5.0 como mínimo universal. EF Core não substitui EF6 sem adaptações.

Comece por uma pequena parte funcional

A base de um projeto ASP.NET Core para avaliar .NET 11 é:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net11.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Use um SDK instalado e explicitamente selecionado, com pacotes compatíveis. O checklist .NET 8 para 11 mostra o pin RC3 atual. Um projeto desktop precisa do TFM Windows e ajustes correspondentes; não transforme todo projeto em Microsoft.NET.Sdk.Web.

Este Program.cs completo é um smoke test, não uma aplicação migrada:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.Run();

Foi compilado, publicado e chamado no .NET 8 e 10 nesta correção. Uma aplicação MVC deve registrar controllers antes de mapeá-los. Autenticação exige esquema e serviços reais; adicionar UseAuthentication() não migra Forms Authentication.

Preserve a semântica de configuração e dados

Um pequeno appsettings.json:

{
  "Migration": {
    "MaxRetries": 3
  }
}

O provider JSON de configuração ignora diferenças entre maiúsculas e minúsculas nas chaves. Isso difere das regras de serialização JSON em geral. Revise precedência e armazenamento de segredos. O provider XML não reproduz automaticamente todas as seções de app.config ou binding redirects. System.Configuration.ConfigurationManager pode ser uma opção para APIs compatíveis; eliminar todo uso não é obrigatório. web.config continua relevante no IIS.

A implementação incorporada de BinaryFormatter lança exceção desde .NET 9, mas o tipo permanece. Use outro serializador ou avalie o leitor NRBF para extrair dados sem instanciar tipos codificados arbitrários. A conversão não exige necessariamente o antigo desserializador inseguro no Framework 4.8.

AssemblyLoadContext permite carregar e descarregar assemblies cooperativamente, mas não recria a fronteira de segurança de AppDomain. Referências, código ativo e eventos podem impedir a descarga. Um ciclo de GC não prova sucesso. Para código não confiável, use fronteira adequada de processo/container e permissões.

Mantenha a validação de certificados. Em falhas TLS, investigue certificado, hostname, cadeia de confiança, configurações SQL e plataforma. Não aceite todos os certificados como solução. Teste formatos/culturas e contratos concretos em vez de presumir uma mudança geral de parsing no .NET 11.

Implante e ensaie rollback

dotnet restore
dotnet build -c Release --no-restore
dotnet test -c Release --no-build
dotnet publish -c Release --self-contained false

O comando publica explicitamente uma aplicação dependente do framework. Uma publicação autocontida exige --self-contained true e RID adequado; não é resultado automático de dotnet publish. Preserve CI Windows para projetos Framework restantes e valide o artefato moderno na plataforma real.

Teste acessos negados além de solicitações bem-sucedidas, sessões, escritas no banco, mensagens, jobs e integrações desktop. Mantenha a implantação antiga disponível, faça mudanças compatíveis e ensaie reverter o tráfego. Rollback exige aplicação e configuração antigas, não apenas reinstalar o redistribuível.

Limites da verificação: Não foram testados aplicação Windows/Framework, SDK .NET 11, serviço WCF, migração EF ou implantação produtiva. Endpoint portável e chaves JSON foram verificados no .NET 8 e 10. Estime esforço e desempenho com uma parte representativa da sua aplicação.

Outras fontes primárias

• AssemblyLoadContext
• .NET Framework technologies unavailable on .NET
• .NET application publishing