Visão geral da portabilidade do .NET Framework para .NET

  • Artigo

Este artigo fornece uma visão geral do que você deve considerar ao portar seu código de .NET Framework para .NET (anteriormente chamado .NET Core). A portabilidade para o .NET do .NET Framework é relativamente simples para muitos projetos. A complexidade de seus projetos determina quanto trabalho você fará após a migração inicial dos arquivos de projeto.

Projetos em que o modelo de aplicativo está disponível no .NET (como bibliotecas, aplicativos de console e aplicativos da área de trabalho) geralmente exigem pouca alteração. Projetos que exigem um novo modelo de aplicativo, como mudar para ASP.NET Core de ASP.NET, exigem mais trabalho. Muitos padrões do modelo de aplicativo antigo têm equivalentes que podem ser usados durante a conversão.

Tecnologias da área de trabalho do Windows

Muitos aplicativos criados para .NET Framework usam uma tecnologia de área de trabalho, como Windows Forms ou Windows Presentation Foundation (WPF). Tanto o Windows Forms quanto o WPF foram portados para o .NET, mas essas tecnologias permanecem somente no Windows.

Considere as seguintes dependências antes de migrar um aplicativo Windows Forms ou WPF:

  1. Os arquivos de projeto para .NET usam um formato diferente do .NET Framework.
  2. Seu projeto pode usar uma API que não está disponível no .NET.
  3. Os controles e bibliotecas de terceiros podem não ter sido portados para o .NET e permanecem disponíveis apenas para .NET Framework.
  4. Seu projeto usa uma tecnologia que não está mais disponível no .NET.

O .NET usa as versões de software livre do Windows Forms e do WPF e inclui aprimoramentos em .NET Framework.

Para ver tutoriais sobre como migrar seu aplicativo da área de trabalho para o .NET 6, confira um dos seguintes artigos:

APIs específicas do Windows

Os aplicativos ainda podem usar bibliotecas nativas P/Invoke em plataformas compatíveis com o .NET. Essa tecnologia não se limita ao Windows. No entanto, se a biblioteca referenciada for específica do Windows, como um user32.dll ou kernel32.dll, o código só funcionará no Windows. Para cada plataforma em que você deseja que seu aplicativo seja executado, você precisará encontrar versões específicas da plataforma ou tornar seu código genérico o suficiente para ser executado em todas as plataformas.

Ao portar um aplicativo do .NET Framework para o .NET, seu aplicativo provavelmente usou uma biblioteca fornecida distribuída com o .NET Framework. Muitas APIs que estavam disponíveis em .NET Framework não foram portadas para o .NET porque contavam com tecnologia específica do Windows, como o Registro do Windows ou o modelo de desenho GDI+.

O Pacote de Compatibilidade do Windows fornece uma grande parte da superfície da API .NET Framework para .NET e é fornecido por meio do pacote NuGet Microsoft.Windows.Compatibility.

Para obter mais informações, consulte Usar o Pacote de Compatibilidade do Windows para fazer a portabilidade pra o .NET.

Modo de compatibilidade do .NET framework

O modo de compatibilidade do .NET Framework foi introduzido a partir do .NET Standard 2.0. Esse modo de compatibilidade permite que os projetos do .NET Standard e do .NET 5+ (e .Net Core 3.1) referenciem bibliotecas do .NET Framework somente no Windows. Fazer referência a bibliotecas do .NET Framework não funciona para todos os projetos, como nos casos em que a biblioteca usa APIs do WPF (Windows Presentation Foundation), mas isso desbloqueia muitos cenários de portabilidade. Para obter mais informações, consulte Analisar suas dependências para o código de portabilidade de .NET Framework para .NET.

Tecnologias indisponíveis

Há algumas tecnologias no .NET Framework que não existem no .NET:

  • Domínios do aplicativo

    Não há suporte para a criação de domínios de aplicativo adicionais. Para isolamento de código, é recomendável usar processos separados e/ou contêineres como uma alternativa.

  • Comunicação remota

    A comunicação remota é usada para se comunicar entre domínios de aplicativo, que não têm mais suporte. 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, considere estruturas como StreamJsonRpc ou ASP.NET Core (usando serviços de API Web gRPC ou RESTful).

  • CAS (Segurança de Acesso do Código)

    CAS era uma técnica de área restrita compatível com .NET Framework, mas preterida no .NET Framework 4.0. Ela foi substituída pela Security Transparency e não tem suporte no .NET. Em vez disso, use limites de segurança fornecidos pelo sistema operacional, como virtualização, contêineres ou contas de usuário.

  • Security transparency

    Semelhante ao CAS, essa técnica de área restrita não é mais recomendada para aplicativos .NET Framework e não tem suporte no .NET. Em vez disso, 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.

  • Windows Workflow Foundation (WF)

    O WF não tem suporte no .NET 5+ (incluindo o .NET Core). Para obter uma alternativa, consulte CoreWF.

Para obter mais informações sobre essas tecnologias sem suporte, consulte tecnologias indisponíveis .NET Framework no .NET Core e no .NET 5+.

Plataforma cruzada

O .NET (anteriormente conhecido como .NET Core) foi projetado para ser multiplataforma. Se o código não depender de tecnologias específicas do Windows, ele poderá ser executado em outras plataformas, como macOS, Linux e Android. Isso inclui tipos de projeto como:

  • Bibliotecas
  • Ferramentas baseadas em console
  • Automação
  • Sites ASP.NET

O .NET Framework é um componente somente do Windows. Quando o código usa tecnologias ou APIs específicas do Windows, como Windows Forms e Windows Presentation Foundation (WPF), o código ainda pode ser executado no .NET, mas não será executado em outros sistemas operacionais.

É possível que sua biblioteca ou aplicativo baseado em console possa ser usado entre plataformas sem muita alteração. Ao fazer a portabilidade para o .NET, talvez você queira levar isso em consideração e testar seu aplicativo em outras plataformas.

O futuro do .NET Standard

O .NET Standard é uma especificação formal de APIs do .NET que estão disponíveis em todas as implementações do .NET. A motivação por trás do .NET Standard era estabelecer maior uniformidade no ecossistema do .NET. A partir do .NET 5, uma abordagem diferente para estabelecer a uniformidade foi adotada e essa nova abordagem elimina a necessidade do .NET Standard em muitos cenários. Para obter mais informações, confira .NET 5 e .NET Standard.

O .NET Standard 2.0 foi a última versão a dar suporte ao .NET Framework.

Ferramentas para auxiliar a portabilidade

Em vez da portabilidade manual de um aplicativo do .NET Framework para o .NET, você pode usar ferramentas diferentes para ajudar a automatizar alguns aspectos da migração. A portabilidade de um projeto complexo é, por si só, um processo complexo. Essas ferramentas podem ajudar nessa jornada.

Mesmo que você use uma ferramenta para ajudar a portar seu aplicativo, examine as Considerações ao portar a seção neste artigo.

Assistente de Atualização do .NET

O Assistente de Atualização do .NET é uma ferramenta de linha de comando que pode ser executada em diferentes tipos de aplicativos do .NET Framework. Ele foi projetado para ajudar na atualização de aplicativos do .NET Framework para o .NET 5. Depois de executar a ferramenta, na maioria dos casos, o aplicativo exigirá esforço adicional para concluir a migração. A ferramenta inclui a instalação de analisadores que podem ajudar na conclusão da migração. Essa ferramenta funciona nos seguintes tipos de aplicativos .NET Framework:

  • Windows Forms
  • WPF
  • ASP.NET MVC
  • Console
  • Bibliotecas de classes

Essa ferramenta usa as outras ferramentas listadas neste artigo e orienta o processo de migração. Para obter mais informações sobre a ferramenta, consulte Visão geral do Assistente de Atualização do .NET.

try-convert

A ferramenta try-convert é uma ferramenta global do .NET que pode converter um projeto ou uma solução inteira no .NET SDK, incluindo a movimentação de aplicativos da área de trabalho para o .NET 5. No entanto, essa ferramenta não será recomendada se o projeto tiver um processo de compilação complicado, como tarefas, destinos ou importações personalizados.

Para obter mais informações, consulte repositório try-convert GitHub

.NET Portability Analyzer

O Analisador de Portabilidade do .NET é uma ferramenta que analisa assemblies e fornece um relatório detalhado sobre APIs .NET ausentes para que os aplicativos ou bibliotecas sejam portáteis em suas plataformas .NET de destino especificadas.

Para usar o analisador de portabilidade do .net no Visual Studio, instale a extensão do marketplace.

Para obter mais informações, consulte O Analisador de Portabilidade do .NET.

Analisador de compatibilidade de plataforma

O Analisador de compatibilidade da plataforma analisa se você está usando ou não uma API que lançará um PlatformNotSupportedException em um tempo de execução. Embora isso não seja comum se você estiver saindo do .NET Framework 4.7.2 ou superior, é bom verificar. Para obter mais informações sobre APIs que geram exceções no .NET, consulte APIs que sempre geram exceções no .NET Core.

Para obter mais informações, consulte Analisador de Compatibilidade da Plataforma.

Considerações durante a portabilidade

Ao fazer a portabilidade do seu aplicativo para o .NET, considere as seguintes sugestões nessa ordem.

✔️ CONSIDERE o uso do Assistente de Atualização do .NET para migrar seus projetos. Embora essa ferramenta esteja em versão prévia, ela automatiza a maioria das etapas manuais detalhadas neste artigo e oferece um ótimo ponto de partida para continuar seu caminho de migração.

✔️ CONSIDERE examinar suas dependências primeiro. Suas dependências devem ter como destino .NET 5, .NET Standard ou .NET Core.

✔️ MIGRE de um arquivo depackages.config NuGet para configurações PackageReference no arquivo de projeto. Use o Visual Studio para converter o arquivopackage.config.

✔️ CONSIDERE a atualização para o formato de arquivo de projeto mais recente, mesmo que você ainda não possa portar seu aplicativo. Projetos .NET Framework usam um formato de projeto desatualizado. Embora o formato de projeto mais recente, conhecido como projetos no estilo SDK, tenha sido criado para o .NET Core e outros, eles trabalham com .NET Framework. Ter o arquivo de projeto no formato mais recente fornece uma boa base para portar seu aplicativo no futuro.

✔️ Redirecione seu projeto de .NET Framework para pelo menos .NET Framework 4.7.2. Isso garante a disponibilidade das alternativas de API mais recentes para casos em que o .NET Standard não dá suporte a APIs existentes.

✔️ CONSIDERE direcionar o .NET 5 em vez do .NET Core 3.1. Embora o .NET Core 3.1 tenha suporte de longo prazo (LTS), o .NET 5 é o mais recente e o .NET 6 será LTS quando lançado.

✔️ DEFINA como destino o .NET 5 para projetos do Windows Forms e WPF. O .NET 5 contém muitas melhorias para aplicativos da Área de Trabalho.

✔️ CONSIDERE direcionar o .NET Standard 2.0 se você estiver migrando uma biblioteca que também pode ser usada com projetos .NET Framework. Você também pode multidirecionar sua biblioteca, direcionando .NET Framework e .NET Standard.

✔️ ADICIONE referência ao pacote NuGet Microsoft.Windows.Compatibility se, após a migração, você receber erros de APIs ausentes. Uma grande parte da superfície da API do .NET Framework está disponível para o .NET por meio do pacote NuGet.

Confira também