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 a código). Se suas bibliotecas dependem de uma ou mais das tecnologias listadas nesta página, considere as abordagens alternativas mencionadas.
Para obter mais informações sobre compatibilidade de API, consulte Alterações significativas no .NET.
Domínios de aplicação
Os domínios de aplicativo (AppDomains) isolam os aplicativos uns dos outros. Os AppDomains requerem suporte de tempo de execução e são caros em termos de recursos. A criação de mais domínios de aplicativo não é suportada 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 AssemblyLoadContext classe.
Para facilitar a migração de código do .NET Framework, o .NET 6+ expõe parte da AppDomain superfície da API. Algumas das APIs funcionam normalmente (por exemplo, AppDomain.UnhandledException), alguns membros não fazem nada (por exemplo, SetCachePath), e alguns deles lançam PlatformNotSupportedException (por exemplo, CreateDomain). Verifique os tipos que você usa em relação à fonte deSystem.AppDomainreferência no repositório GitHub dotnet/runtime. Certifique-se de selecionar a ramificação que corresponde à sua versão implementada.
Comunicação remota
A comunicação remota do .NET não é suportada no .NET 6+. A comunicação remota do .NET foi identificada como uma arquitetura problemática. Ele é usado para comunicação entre domínios de aplicativos, que não são mais suportados. Além disso, a comunicação remota requer suporte de tempo de execução, que é caro de manter.
Para uma comunicação simples entre processos, considere os mecanismos de comunicação entre processos (IPC) como uma alternativa à comunicação remota, como a System.IO.Pipes classe ou a MemoryMappedFile classe. Para cenários mais complexos, o projeto StreamJsonRpc de código aberto fornece uma estrutura de comunicação remota .NET Standard de plataforma cruzada que funciona sobre conexões de fluxo ou pipe existentes.
Em todas as máquinas, use uma solução baseada em rede como alternativa. De preferência, use um protocolo de texto simples 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 o uso 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) através de soquetes da web.
Para obter mais opções de mensagens, consulte .NET Open Source Developer Projects: Messaging.
Como a comunicação remota não é suportada, as chamadas para BeginInvoke() e EndInvoke() em objetos delegados serão lançadas PlatformNotSupportedException. Para obter mais informações, consulte Migrando chamadas de delegado BeginInvoke para .NET Core.
Segurança de acesso ao código (CAS)
Sandboxing, que depende do tempo de execução ou da estrutura para restringir quais recursos um aplicativo gerenciado ou biblioteca usa ou executa, não é suportado no .NET Framework e, portanto, também não é suportado no .NET 6+. O CAS não é mais tratado como um limite de segurança, porque há muitos casos no .NET Framework e no tempo de execução 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 desempenho de correção para aplicativos que não pretendem usá-lo.
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 da segurança
Semelhante ao CAS, a transparência de segurança separa o código em área restrita do código crítico de segurança de forma declarativa, mas não é mais suportada 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 é suportado pelo .NET 6+.
Base do fluxo de trabalho
O Windows Workflow Foundation (WF) não é suportado no .NET 6+. Para obter uma alternativa, consulte CoreWF.
Gorjeta
O servidor Windows Communication Foundation (WCF) pode ser usado no .NET 6+ usando os pacotes NuGet CoreWCF. Para obter mais informações, consulte CoreWCF 1.0 foi lançado.
Algumas APIs de emissão de reflexão não são suportadas
O .NET 8 e versões anteriores do .NET (Core) não suportam salvar assemblies gerados pelas System.Reflection.Emit APIs e o AssemblyBuilder.Save método não está disponível. Além disso, os seguintes campos da AssemblyBuilderAccess enumeração não estão disponíveis:
No .NET 9, um PersistedAssemblyBuilder foi implementado e o AssemblyBuilder.Save método foi adicionado de volta à biblioteca de emissão de reflexo. Para saber mais sobre como usar essa API, consulte System.Reflection.Emit.PersistedAssemblyBuilder classe.
Para obter mais informações sobre as diferentes implementações do AssemblyBuilder no .NET, consulte Classe System.Reflection.Emit.AssemblyBuilder
Carregando montagens multimódulo
Assemblies que consistem em vários módulos (OutputType=Module no MSBuild) não são suportados no .NET 6+.
Como alternativa, considere mesclar os módulos individuais em um único arquivo de montagem.
Blocos de script XSLT
Os blocos de script XSLT são suportados apenas no .NET Framework. Eles não são suportados no .NET 6 ou posterior.
