Tecnologias do .NET Framework indisponíveis no .NET
Várias tecnologias disponíveis para bibliotecas do .NET Framework não estão disponíveis para uso com o .NET 6+, como domínios de aplicativo, comunicação remota e CAS (segurança de acesso de código). Se suas bibliotecas dependerem de uma ou mais das tecnologias listadas nesta página, considere as abordagens alternativas mencionadas.
Para obter mais informações sobre compatibilidade com a API, consulte Alterações significativas no .NET.
Domínios de aplicativo
Os domínios de aplicativo (AppDomains) isolam os aplicativos uns dos outros. Os AppDomains exigem suporte de runtime e são caros para recursos. Não há suporte para a criação de mais domínios de aplicativo e não há planos para adicionar esse recurso no futuro. Para isolamento de código, use processos ou contêineres separados como alternativa. Para carregar assemblies dinamicamente, use a classe AssemblyLoadContext.
Para facilitar a migração de código do .NET Framework, o .NET 6+ expõe parte da superfície da API AppDomain. Algumas das APIs funcionam normalmente (por exemplo, AppDomain.UnhandledException), alguns membros não fazem nada (por exemplo, SetCachePath) e alguns deles geram PlatformNotSupportedException (por exemplo, CreateDomain). Verifique os tipos de você usa em relação à System.AppDomain origem da referência no repositório dotnet/runtime GitHub. Selecione o branch que corresponde à sua versão implementada.
Comunicação remota
O .NET Remoting não é suportado no .NET 6+. A comunicação remota do .NET foi identificada como uma arquitetura problemática. Ele é usado para se comunicar entre domínios de aplicativo, que não têm mais suporte. Além disso, a comunicação remota exige suporte de runtime, o que é caro para manter.
Para comunicação entre processos, considere mecanismos IPC (comunicação entre processos) como uma alternativa à Comunicação Remota, tais como a classe System.IO.Pipes ou MemoryMappedFile. Para cenários mais complexos, o projeto StreamJsonRpc de software livre fornece uma estrutura de comunicação remota do .NET Standard multiplataforma que funciona sobre conexões de fluxo ou pipe existentes.
Entre computadores, use uma solução baseada em rede como alternativa. De preferência, use um protocolo de texto sem formatação de baixa sobrecarga, como HTTP. O servidor Web Kestrel, que é o servidor Web usado pelo ASP.NET Core, é uma opção aqui. Além disso, considere usar System.Net.Sockets para cenários entre máquinas baseados em rede. StreamJsonRpc, mencionado anteriormente, pode ser usado para comunicação JSON ou binária (via MessagePack) por meio de soquetes da Web.
Para ter mais opções de mensagens, veja .NET Open Source Developer Projects: Messaging.
Como não há suporte para comunicação remota, chamadas para BeginInvoke() e EndInvoke() em objetos delegados geram PlatformNotSupportedException. Para saber mais, confira Migrando chamadas BeginInvoke de delegado para o .NET Core.
CAS (segurança de acesso ao código)
O sandboxing, que depende do runtime ou da estrutura para restringir quais recursos um aplicativo gerenciado ou biblioteca usa ou executa, não tem suporte no .NET Framework e, portanto, também não tem suporte no .NET 6+. O CAS não é mais tratado como um limite de segurança, pois há muitos casos no .NET Framework e no runtime em que ocorre uma elevação de privilégios. Além disso, o CAS torna a implementação mais complicada e geralmente tem implicações de correção e desempenho para aplicativos que não pretendem usá-la.
Use os limites de segurança fornecidos pelo sistema operacional, como virtualização, contêineres ou contas de usuário, para executar processos com o conjunto mínimo de privilégios.
Transparência de segurança
Assim como a CAS, a Transparência de segurança separa o código em área restrita do código crítico de segurança de uma forma declarativa, mas não é mais permitida como um limite de segurança. Esse recurso é muito usado pelo Silverlight.
Para executar processos com o menor conjunto de privilégios, use os limites de segurança fornecidos pelo sistema operacional, como virtualização, contêineres ou contas de usuário.
System.EnterpriseServices
System.EnterpriseServices (COM+) não tem suporte do .NET 6+.
Workflow Foundation
Não há suporte para o WF (Windows Workflow Foundation) no .NET 6+. Para obter uma alternativa, consulte CoreWF.
Dica
O servidor WCF (Windows Communication Foundation) pode ser usado no .NET 6+ usando os pacotes NuGet do CoreWCF. Para obter mais informações, confira Se o CoreWCF 1.0 foi lançado.
Não há suporte para algumas APIs de emissão de reflexão
O .NET 8 e versões anteriores do .NET (Core) não dão suporte ao salvamento de assemblies gerados pelas APIs de System.Reflection.Emit e o método AssemblyBuilder.Save não está disponível. Além disso, os seguintes campos da enumeração AssemblyBuilderAccess não estão disponíveis:
No .NET 9, um PersistedAssemblyBuilder foi implementado e o método AssemblyBuilder.Save foi adicionado de volta à biblioteca de emissão de reflexão. Para saber mais sobre como usar essa API, consulte classe System.Reflection.Emit.PersistedAssemblyBuilder.
Para obter mais informações sobre as diferentes implementações do AssemblyBuilder no .NET, consulte classe System.Reflection.Emit.AssemblyBuilder.
Carregando assemblies de vários módulos
Não há suporte para assemblies que consistem em vários módulos (OutputType=Module no MSBuild) no .NET 6+.
Como alternativa, considere mesclar os módulos individuais em um único arquivo de assembly.
Blocos de script XSLT
Os blocos de script de XSLT têm suporte apenas no .NET Framework. Eles não têm suporte no .NET 6 ou posterior.
