Compartilhar via

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

Este artigo fornece uma visão geral do que você deve considerar ao portar seu código do .NET Framework para o .NET (anteriormente denominado .NET Core). A portabilidade para .NET do .NET Framework é relativamente simples para muitos projetos. A complexidade de seus projetos determina quanto trabalho você precisará fazer após a migração inicial dos arquivos do 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 mover 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 o .NET Framework usam uma tecnologia de área de trabalho, como o Windows Forms ou o WPF (Windows Presentation Foundation). Os Windows Forms e o WPF estão disponíveis no .NET, mas permanecem tecnologias somente do Windows.

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

  • Os arquivos de projeto para .NET usam um formato diferente do .NET Framework.
  • Seu projeto pode usar uma API que não está disponível no .NET.
  • Os controles e bibliotecas de terceiros podem não ter sido portados para o .NET e permanecem disponíveis apenas para o .NET Framework.
  • 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 no .NET Framework.

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

APIs específicas do Windows

Os aplicativos ainda podem P/Invocar bibliotecas nativas em plataformas compatíveis com o .NET. Essa tecnologia não se limita ao Windows. No entanto, se a biblioteca que você está fazendo referência 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ê precisa encontrar versões específicas da plataforma ou tornar seu código genérico o suficiente para ser executado em todas as plataformas.

Quando você estiver portando um aplicativo do .NET Framework para o .NET, seu aplicativo provavelmente usou uma biblioteca fornecida pelo .NET Framework. Muitas APIs que estavam disponíveis no .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 do .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 portar o código para o .NET.

Modo de compatibilidade do .NET Framework

O modo de compatibilidade do .NET Framework foi introduzido no .NET Standard 2.0. O modo de compatibilidade permite que os projetos .NET Standard e .NET referenciem bibliotecas do .NET Framework como se fossem compiladas para a estrutura de destino do projeto. No entanto, algumas implementações do .NET podem dar suporte a uma parte maior do .NET Framework do que outras. Por exemplo, o .NET Core 3.0 estende o modo de compatibilidade do .NET Framework para Windows Forms e WPF. Fazer referência a bibliotecas do .NET Framework não funciona para todos os projetos, como se a biblioteca usa APIs do WPF, mas desbloqueia muitos cenários de portabilidade. Para obter mais informações, consulte Analisar suas dependências para portar código do .NET Framework para o .NET.

Fazer referência a bibliotecas do .NET Framework não funciona em todos os casos, pois depende de quais APIs do .NET Framework foram usadas e se essas APIs têm suporte ou não na estrutura de destino do projeto. Além disso, algumas das APIs do .NET Framework funcionarão apenas no Windows. O modo de compatibilidade do .NET Framework desbloqueia muitos cenários de portabilidade, mas você deve testar seus projetos para garantir que eles também funcionem em runtime. Para obter mais informações, consulte Analisar suas dependências para portar código do .NET Framework para.

Alterações no framework de destino em projetos estilo SDK

Como mencionado anteriormente, os arquivos de projeto do .NET usam um formato diferente do .NET Framework, conhecido como o formato de projeto no estilo SDK. Mesmo que você não esteja migrando do .NET Framework para o .NET, você ainda deverá atualizar o arquivo de projeto para o formato mais recente. A maneira de especificar uma estrutura de destino é diferente em projetos no estilo SDK. No .NET Framework, a <TargetFrameworkVersion> propriedade é usada com um moniker que especifica a versão do .NET Framework. Por exemplo, o .NET Framework 4.7.2 tem a seguinte aparência:

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

Um projeto no estilo SDK usa uma propriedade diferente para identificar a estrutura de destino, a <TargetFramework> propriedade. Ao direcionar o .NET Framework, o moniker começa com net e termina com a versão do .NET Framework sem pontos finais. Por exemplo, o moniker para o .NET Framework 4.7.2 é net472:

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

Para obter uma lista de todos os monikers de destino, consulte as estruturas de destino em projetos no estilo SDK.

Tecnologias indisponíveis

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

  • Domínios de aplicativo

    Não há suporte para a criação de domínios de aplicativo adicionais. Para isolamento de código, use processos ou contêineres separados como 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).

    Como não há suporte para comunicação remota, as chamadas de BeginInvoke() e EndInvoke() em objetos delegados lançarão PlatformNotSupportedException.

  • CAS (segurança de acesso ao código)

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

  • Transparência de segurança

    Semelhante ao CAS, a técnica de área restrita de transparência de segurança não é mais recomendada para aplicativos do .NET Framework e não tem suporte no .NET. Em vez disso, use os limites de segurança fornecidos pelo sistema operacional, como virtualização, contêineres ou contas de usuário.

  • System.EnterpriseServices

    System.EnterpriseServices Não há suporte para (COM+) no .NET.

  • Windows Workflow Foundation (WF)

    O WF não tem suporte no .NET. Para obter uma alternativa, consulte CoreWF.

Para obter mais informações sobre essas tecnologias sem suporte, consulte as tecnologias do .NET Framework indisponíveis no .NET 6+.

Multiplataforma

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. Esse código inclui tipos de projeto como:

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

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

É possível que sua biblioteca ou aplicativo baseado em console possa ser usado entre plataformas sem alterar muito. Ao fazer a portabilidade para o .NET, convém 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 .NET que estão disponíveis em várias implementações do .NET. A motivação por trás do .NET Standard foi 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 de .NET Standard em muitos cenários. Para obter mais informações, consulte .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 de portar manualmente 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. As ferramentas podem ajudar nesse percurso.

Mesmo se você usar uma ferramenta para ajudar a portar seu aplicativo, deve revisar a seção Considerações ao portar 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. Depois de executar a ferramenta, na maioria dos casos, o aplicativo exigirá mais esforço para concluir a migração. A ferramenta inclui a instalação de analisadores que podem auxiliar na conclusão da migração. Essa ferramenta funciona nos seguintes tipos de aplicativos do .NET Framework:

  • Windows Forms
  • WPF (Windows Presentation Foundation)
  • ASP.NET MVC
  • Consolar
  • Bibliotecas de classes

Essa ferramenta usa as outras ferramentas listadas neste artigo, como try-convert, 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 try-convert ferramenta é uma ferramenta global do .NET que pode converter um projeto ou uma solução inteira no SDK do .NET, incluindo a movimentação de aplicativos da área de trabalho para o .NET. No entanto, essa ferramenta não será recomendada se o projeto tiver um processo de build complicado, como tarefas personalizadas, destinos ou importações.

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

Analisador de compatibilidade de plataforma

O analisador de compatibilidade da plataforma analisa se você está usando ou não uma API que lança um PlatformNotSupportedException durante o tempo de execução. Embora encontrar uma dessas APIs seja improvável se você estiver migrando 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 o analisador de compatibilidade da plataforma.

Considerações para portabilidade

Ao portar seu aplicativo para o .NET, considere as seguintes sugestões na 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 ser direcionadas para .NET, .NET Standard ou .NET Core.

✔️ FAÇA a migração de um arquivo NuGet packages.config para as PackageReference configurações no arquivo de projeto. Use o Visual Studio para converter o package.config arquivo.

✔️ CONSIDERE a atualização para o formato de arquivo de projeto mais recente, mesmo que você ainda não possa portar seu aplicativo. Os projetos do .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 além, o formato também funciona com o .NET Framework. Ter o arquivo de projeto no formato mais recente fornece uma boa base para portar seu aplicativo no futuro.

✔️ Faça o redirecionamento do projeto do .NET Framework para pelo menos o .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 o direcionamento para o .NET 8, que é uma versão LTS (suporte de longo prazo).

✔️ DO tem como destino o .NET 6+ para projetos do Windows Forms e do WPF . O .NET 6 e versões posteriores 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 do .NET Framework. Você também pode configurar sua biblioteca para múltiplos alvos, tornando-a compatível com o .NET Framework e o .NET Standard.

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

Consulte também