Tecnologias do .NET Framework não disponíveis no .NET Core

  • Artigo

Várias tecnologias disponíveis para as bibliotecas do .NET Framework não estão disponíveis para uso com o .NET 6+ , como domínios de aplicativos, comunicação remota e CAS (segurança de acesso do 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 do aplicativo (AppDomains) isolam os aplicativos uns dos outros. Os AppDomains exigem suporte de runtime e geralmente são muito caros em termos de 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, é recomendável usar processos separados e/ou contêineres como uma alternativa. Para carregar assemblies dinamicamente, use a classe AssemblyLoadContext.

Para facilitar a migração do 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 geram PlatformNotSupportedException (por exemplo, CreateDomain). Verifique os tipos de você usa em relação à System.AppDomainorigem da referência no repositório dotnet/runtime GitHub. Selecione o branch que corresponde à sua versão implementada.

Comunicação remota

Não há suporte para a comunicação remota do .NET no .NET 6+. A comunicação remota do .NET foi identificada como uma arquitetura problemática. Ela é usada 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 sobrecarga baixa, como HTTP. O servidor Web Kestrel, que é o servidor Web usado pelo ASP.NET Core, é uma opção. Considere também o uso de System.Net.Sockets para cenários entre computadores 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 do Código)

A área restrita, que depende do runtime ou da estrutura para restringir quais recursos um aplicativo gerenciado ou uma biblioteca usa ou executa, não é compatível com o .NET Framework e, portanto, também não é compatível com o .NET 6+. A CAS não é mais tratada como um limite de segurança, pois existem muitos casos no .NET Framework e no runtime em que ocorre uma elevação de privilégios. Além disso, a CAS complica mais a implementação e geralmente tem implicações de desempenho de exatidão em 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 é amplamente usado pelo Silverlight.

Para executar processos com o conjunto mínimo de privilégios, use 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 no .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 as versões anteriores do .NET (Core) não são compatíveis com o salvamento de assemblies gerados pelas APIs 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, confira a classe System.Reflection.Emit.AssemblyBuilder.

Para obter mais informações, confira problema #15704 dotnet/runtime.

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 XSLT têm suporte apenas no .NET Framework. Não há suporte para eles no .NET 6 ou posterior.

Confira também