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:
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 .NET Framework.
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.
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:
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.
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 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.
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.
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.
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.
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.
✔️ 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.