Partilhar 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 chamado .NET Core). A portabilidade do .NET Framework para o .NET é relativamente simples para muitos projetos. A complexidade de seus projetos dita quanto trabalho você precisará fazer após a atualizaçã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 de área de trabalho, geralmente exigem poucas alterações. Projetos que exigem um novo modelo de aplicativo, como a mudança do ASP.NET para o ASP.NET Core, exigem mais trabalho. Muitos padrões do modelo de aplicativo antigo têm equivalentes que podem ser usados durante a conversão.

Tecnologias de ambiente de trabalho do Windows

Muitos aplicativos criados para o .NET Framework usam uma tecnologia de área de trabalho, como Windows Forms ou Windows Presentation Foundation (WPF). O Windows Forms e o WPF estão disponíveis no .NET, mas continuam a ser tecnologias apenas para Windows.

Considere as seguintes dependências antes de atualizar um aplicativo Windows Forms ou 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.
  • Controles e bibliotecas de terceiros podem não ter sido portados para o .NET e permanecer 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 código aberto do Windows Forms e do WPF e inclui aprimoramentos sobre o .NET Framework.

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

APIs específicas do Windows

Os aplicativos ainda podem P/Invoke bibliotecas nativas em plataformas suportadas pelo .NET. Esta tecnologia não se limita ao Windows. No entanto, se a biblioteca que você está referenciando for específica do Windows, como um user32.dll ou kernel32.dll, o código só funciona 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ê está 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 dependiam de 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 o .NET e é fornecido por meio do pacote NuGet Microsoft.Windows.Compatibilidade.

Para obter mais informações, consulte Usar o Pacote de Compatibilidade do Windows para portar código para .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 projetos .NET Standard e .NET façam referência a bibliotecas do .NET Framework como se fossem compiladas para a estrutura de destino do projeto. No entanto, algumas implementações .NET podem oferecer 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. A 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.

Referenciar 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 são ou não suportadas pela estrutura de destino do projeto. Além disso, algumas das APIs do .NET Framework só funcionarão 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 tempo de execução. Para obter mais informações, consulte Analisar suas dependências para portar o código do .NET Framework para.

Alterações na plataforma de destino em projetos do tipo SDK

Como mencionado anteriormente, os arquivos de projeto para .NET usam um formato diferente do .NET Framework, conhecido como o formato de projeto no estilo SDK. Mesmo que você não esteja mudando do .NET Framework para o .NET, você ainda deve 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 é apresentado como o seguinte trecho:

<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 nenhum ponto. Por exemplo, o moniker para direcionar o .NET Framework 4.7.2 é net472:

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

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

Tecnologias indisponíveis

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

  • Domínios de aplicação

    Não há suporte para a criação de outros domínios de aplicativo. Para isolamento de código, use processos ou contêineres separados como alternativa.

  • Comunicação remota

    A comunicação remota é usada para comunicação entre domínios de aplicativos, que não são mais suportados. Para uma comunicação simples entre processos, considere os mecanismos de comunicação entre processos (IPC) como uma alternativa à comunicação remota, como a classe System.IO.Pipes ou a classe MemoryMappedFile. Para cenários mais complexos, considere estruturas como StreamJsonRpc ou ASP.NET Core (usando serviços de API Web gRPC ou RESTful).

    Como a comunicação remota não é suportada, as chamadas para BeginInvoke() e EndInvoke() em objetos delegados lançam PlatformNotSupportedException.

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

    O CAS era uma técnica de sandboxing suportada pelo .NET Framework, mas preterida no .NET Framework 4.0. Ele foi substituído pela Transparência de Segurança e não é suportado no .NET. Em vez disso, use limites de segurança fornecidos pelo sistema operacional, como virtualização, contêineres ou contas de usuário.

  • Transparência da segurança

    Semelhante ao CAS, a técnica de sandboxing de transparência de segurança não é mais recomendada para aplicativos .NET Framework e não é suportada 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 é suportado no .NET.

  • Fundação do Fluxo de Trabalho do Windows (WF)

    WF não é suportado no .NET. Para obter uma alternativa, consulte CoreWF.

Para obter mais informações sobre essas tecnologias sem suporte, consulte Tecnologias do .NET Framework não disponíveis no .NET 6+.

Multiplataforma

O .NET (anteriormente conhecido como .NET Core) foi projetado para ser multiplataforma. Se o seu 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:

  • Libraries
  • Ferramentas baseadas em console
  • Automatização
  • sítios 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 mudar 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 do .NET que estão disponíveis em várias implementações do .NET. A motivação por trás do .NET Standard era estabelecer uma maior uniformidade no ecossistema .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, consulte .NET 5+ e .NET Standard.

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

Ferramentas para suporte de portabilidade

Em vez de portar manualmente um aplicativo do .NET Framework para o .NET, você pode usar diferentes ferramentas para ajudar a automatizar alguns aspetos da atualização. Portar um projeto complexo é, em si mesmo, um processo complexo. As ferramentas podem ajudar nessa jornada.

Mesmo se você usar uma ferramenta para ajudar a portar seu aplicativo, você deve revisar a seção Considerações ao portar neste artigo.

Assistente de modernização do aplicativo GitHub Copilot

A modernização do aplicativo GitHub Copilot é um assistente de chat do GitHub Copilot que ajuda você a planejar e atualizar projetos para versões mais recentes do .NET, migrar para o Azure, atualizar dependências e aplicar correções de código. A migração do Azure é alimentada pela avaliação de aplicativos e códigos para .NET

Este assistente de chat suporta os seguintes caminhos de atualização:

  • Atualize projetos de versões mais antigas do .NET para as mais recentes.
  • Atualize projetos do .NET Framework para a versão mais recente do .NET.
  • Modernize sua base de código com novos recursos.
  • Migre componentes e serviços para o Azure.

Também trabalha em vários tipos de projetos, tais como:

  • ASP.NET e tecnologias relacionadas, como MVC, Razor Pages, Web API
  • Blazor
  • Funções do Azure
  • Arquitectura de Apresentação do Windows
  • Windows Forms
  • Bibliotecas de classes
  • Aplicações de consola

Quando usar:

Use a modernização do aplicativo GitHub Copilot quando quiser uma experiência completa e alimentada por IA para atualizar projetos e dependências do .NET Framework para o .NET moderno, abrangendo avaliação, planejamento, correção e orientação para migrar aplicativos para o Azure.

Avaliação de aplicativos e códigos para .NET

O Azure Migrate application and code assessment for .NET fornece análise de código e aplicativo, juntamente com recomendações para planejar implantações na nuvem. Ele ajuda você a executar com confiança soluções críticas para os negócios na nuvem, oferecendo uma avaliação focada no desenvolvedor do seu código-fonte. A ferramenta também fornece recomendações e exemplos para otimizar o código e as configurações do Azure, seguindo as práticas recomendadas do setor.

Essa ferramenta também é usada pela modernização do aplicativo GitHub Copilot para a experiência .NET.

Quando usar:

Use o aplicativo Azure Migrate e o conjunto de ferramentas de avaliação de código para .NET para uma avaliação e recomendações para migrar uma base de código existente para o Azure. A avaliação de código e aplicativo Azure Migrate é essencialmente um subconjunto da modernização do aplicativo GitHub Copilot para a experiência .NET.

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 atualização. A ferramenta inclui a instalação de analisadores que podem ajudar a completar a atualizaçã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, como try-convert, e orienta o processo de atualização. Para obter mais informações sobre a ferramenta, consulte Visão geral do Assistente de atualização do .NET.

Quando usar:

Use quando uma solução alimentada por IA, como a modernização do aplicativo GitHub Copilot, não estiver disponível.

try-convert

A try-convert ferramenta é uma ferramenta global do .NET que pode converter um projeto ou uma solução inteira para o SDK do .NET, incluindo mover aplicativos da área de trabalho para o .NET. No entanto, essa ferramenta não é recomendada se seu projeto tiver um processo de compilação 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 Platform compatibility analyzer analisa se está ou não a usar uma API que gera um PlatformNotSupportedException em tempo de execução. Embora seja improvável encontrar uma dessas APIs se você estiver mudando do .NET Framework 4.7.2 ou superior, é bom verificar. Para obter mais informações sobre APIs que lançam exceções no .NET, consulte APIs que sempre lançam exceções no .NET Core.

Para obter mais informações, consulte Analisador de compatibilidade de plataforma.

Considerações sobre a portabilidade

Ao portar seu aplicativo para .NET, considere as seguintes sugestões na ordem:

✔️ CONSIDERE usar a modernização do aplicativo GitHub Copilot para atualizar seus projetos. O GitHub Copilot é poderoso para identificar e corrigir incompatibilidades durante a portabilidade. Ele automatiza a maioria das etapas manuais detalhadas neste artigo e oferece um ótimo ponto de partida para continuar seu caminho de atualização.

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

✔️ Atualize de um arquivo packages.config do NuGet para as PackageReference configurações no arquivo do projeto. Use o Visual Studio para converter o package.config arquivo.

✔️ CONSIDERE atualizar 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 seu arquivo de projeto no formato mais recente oferece uma boa base para portar seu aplicativo no futuro.

✔️ REDIRECIONE seu 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 oferece suporte a APIs existentes.

✔️ CONSIDERE usar o .NET 8, que é uma versão de suporte de longo prazo (LTS).

✔️ DEV definir o .NET 8+ para projetos Windows Forms e WPF. O .NET 8 e versões posteriores contêm muitas melhorias para aplicativos da área de trabalho.

✔️ Considerar o direcionamento para o .NET Standard 2.0 ao atualizar uma biblioteca que também possa ser utilizada em projetos do .NET Framework. Você também pode configurar sua biblioteca para suportar múltiplos ambientes, abrangendo tanto o .NET Framework quanto o .NET Standard.

✔️ ADICIONE referência ao pacote NuGet Microsoft.Windows.Compatibility, se, após a migração, 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.

Consulte também

  • Last updated on