Em setembro, lançamos o suporte do .NET Core para a criação de aplicativos de área de trabalho do Windows, incluindo WPF e Windows Forms. Desde então, temos o prazer de ver muitos desenvolvedores compartilhando suas histórias sobre como portar aplicativos de desktop para o .NET Core. Ouvimos constantemente histórias de desenvolvedores .NET de aplicativos de área de trabalho do Windows sobre como eles suportam seus negócios com o WPF e o Windows Forms, especialmente quando a área de trabalho vence, incluindo:
- Aplicativos FOD (formulários sobre dados) com uma interface de usuário densa
- Interface de usuário responsiva e de baixa latência
- Aplicativos que devem funcionar offline
- Aplicativos com dependências em drivers de dispositivo personalizados
Dê uma olhada para saber mais sobre os benefícios do .NET Core para a criação de aplicativos Windows.
Por que a área de trabalho do Windows no .NET Core?
O .NET Core (e no futuro o .NET 5, construído com base no .NET Core) se tornará o futuro do .NET. Nós nos esforçamos para oferecer suporte ao .NET Framework o máximo possível, mas ele não receberá nenhum novo recurso; eles serão adicionados apenas ao .NET Core (e, finalmente, ao .NET 5). Para melhorar as pilhas da área de trabalho do Windows e permitir que os desenvolvedores da área de trabalho .NET se beneficiem de todas as atualizações futuras, introduzimos o Windows Forms e o WPF para .NET Core. Eles continuarão sendo tecnologias somente para Windows, pois estão intimamente relacionados às APIs do Windows. Mas o .NET Core, além da plataforma cruzada, possui muitos outros recursos que podem melhorar os aplicativos de desktop.
Antes de tudo, todos os aprimoramentos de tempo de execução e recursos de idioma serão adicionados apenas no .NET Core e, futuramente, no .NET 5. Um bom exemplo aqui é o C # 8, que ficou disponível no .NET Core 3.0. Além disso, as versões do .NET Forms do Windows Forms e do WPF se tornarão parte da plataforma .NET 5. E, portando seu aplicativo para o .NET Core, você o prepara para o .NET 5.
Além disso, o .NET Core fornece flexibilidade de implantação para seus aplicativos com novas opções não disponíveis no .NET Framework, como:
- Implantação paralela Agora você pode ter várias versões do .NET Core em um computador e escolher em qual versão cada um dos seus aplicativos deve se concentrar.
- Implantação offline. Você pode implantar a plataforma .NET Core com seus aplicativos e se tornar completamente independente do ambiente do usuário final - seu aplicativo tem tudo o que você precisa para executar em qualquer computador com Windows.
- Tamanhos de aplicativos menores. No .NET Core 3, introduzimos um novo recurso chamado vinculador (também chamado de aparador) que analisará seu código e incluirá em uma implantação autônoma apenas os assemblies do .NET Core necessários para o seu aplicativo. Portanto, todos os detalhes da plataforma que não forem usados no seu caso serão excluídos.
- Arquivos .exe únicos. Você pode compactar seu aplicativo e a plataforma .NET Core em um único arquivo .exe.
- Desempenho de tempo de execução aprimorado. O .NET Core tem muitas otimizações de desempenho no .NET Framework. Se você se lembra do histórico do .NET Core, criado originalmente para as cargas de trabalho na Web e no servidor, ajuda a entender se seu aplicativo pode obter benefícios visíveis ao otimizar o tempo de execução. Em particular, os aplicativos de área de trabalho que são altamente dependentes das operações de E / S de arquivo, rede e banco de dados provavelmente mostram melhorias de desempenho para esses cenários. Algumas áreas nas quais você pode não perceber alterações significativas estão relacionadas ao desempenho da renderização da interface com o usuário ou ao lançamento do aplicativo.
Ao definir as propriedades
<PublishSingleFile> ,
<RuntimeIdentifier> e
<PublishTrimmed> no perfil da publicação, você pode implantar o aplicativo independente cortado como um único arquivo .exe, conforme mostrado no exemplo abaixo.
<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup>
Diferenças entre a área de trabalho do .NET Framework e a área de trabalho do .NET Core
Ao desenvolver aplicativos de área de trabalho, você não notará uma grande diferença entre as versões do WPF e do Windows Forms para o .NET Framework e .NET Core. Parte de nossos esforços tem sido fornecer semelhanças funcionais entre essas plataformas de desktop e aprimorar o futuro do .NET Core.
Os aplicativos WPF são totalmente suportados no .NET Core e você pode começar a trabalhar com eles enquanto trabalhamos em pequenas atualizações e melhorias. Para o Windows Forms, o tempo de execução foi completamente portado para o .NET Core e a equipe está atualmente trabalhando no Windows Forms Designer. Planejamos prepará-lo para o quarto trimestre de 2020, mas por enquanto você pode verificar a versão preliminar do designer no
Visual Studio 16.4 Preview 3 ou posterior. Lembre-se de marcar a caixa em Ferramentas-> Opções-> Recursos de visualização-> Use o Designer de visualização do Windows Forms para aplicativos .NET Core e reinicie o Visual Studio. Lembre-se de que a experiência com o uso ainda é limitada, pois o trabalho ainda está em andamento.
Mudanças importantes
Houve algumas
mudanças importantes no .NET Framework e no .NET Core, mas a maior parte do código relacionado às áreas Windows Forms e WPF foi portada para o Core da mesma maneira. Se você já usou componentes como Cliente WCF, Segurança de Acesso ao Código, Domínios de Aplicativos, Interoperabilidade e Comunicação Remota, precisará refatorar o código se desejar mudar para o .NET Core.
Um aspecto a ter em mente: os caminhos de saída padrão no .NET Core são diferentes dos caminhos no .NET Framework, portanto, se o seu código tiver algumas suposições sobre a estrutura de arquivos / pastas do aplicativo em execução, provavelmente ocorrerá em tempo de execução.
Também há alterações na configuração das funções do .NET. Em vez de usar o arquivo
machine.config , o .NET Core usa o arquivo
<something>.runtimeconfig.json que acompanha o aplicativo e tem o mesmo objetivo principal e informações semelhantes. Algumas configurações, como
system.diagnostics ,
system.net ou
system.servicemodel , não são suportadas, portanto, o arquivo de configuração do aplicativo não poderá ser carregado se contiver alguma dessas seções. Essa alteração se aplica aos scripts de rastreamento
System.Diagnostics e de cliente WCF que foram configurados anteriormente normalmente usando a configuração XML. No .NET Core, você precisa configurá-los no código. Para alterar o comportamento sem recompilar, considere configurar tipos de rastreamento e WCF usando valores baixados de uma fonte
Microsoft.Extensions.Configuration ou de
appSettings .
Você pode encontrar mais informações sobre as diferenças entre o .NET Core e o .NET Framework na
documentação .
Para começar
Confira estes tutoriais curtos:
Portando do .NET Framework para o .NET Core
Primeiro, inicie o
Portability Analyzer (analisador de portabilidade) e, se necessário, atualize o código para garantir 100% de compatibilidade com o .NET Core. Aqui estão as
instruções para usar o analisador de portabilidade. . Recomendamos que você use o controle de origem ou faça um backup do seu código antes de fazer alterações no seu aplicativo, caso a refatoração falhe do jeito que você deseja e decida retornar ao seu estado original.
Quando seu aplicativo for totalmente compatível com o .NET Core, você estará pronto para portá-lo. Como ponto de partida, você pode experimentar a ferramenta que criamos para ajudar a automatizar a conversão de seus projetos do .NET Framework em .NET Core -
try-convert .
É importante lembrar que esta ferramenta é apenas um ponto de partida em sua jornada para o .NET Core. Além disso, este não é um produto da Microsoft suportado. Embora possa ajudá-lo com alguns dos aspectos mecânicos da migração, ele não trata de todos os cenários ou tipos de projeto. Se houver projetos em sua solução que a ferramenta rejeite ou não possa converter, você precisará transferi-los manualmente. Não se preocupe, preparamos muitas lições sobre como fazer isso (no final do artigo).
A ferramenta try-convert tentará transferir os arquivos de projeto no estilo antigo para o novo estilo SDK e reconfigurar os projetos correspondentes no .NET Core. Para suas bibliotecas, deixamos a escolha da plataforma: .NET Core ou .NET Standard. Você pode especificar um deles no arquivo de projeto, atualizando o valor para
<TargetFramework> . Bibliotecas sem dependências específicas do .NET Core, como WPF ou Windows Forms, podem se beneficiar da escolha do .NET Standard:
<TargetFramework>netstandard2.1</TargetFramework>
para que possam ser usados pelos chamadores que segmentam muitas plataformas .NET diferentes. Por outro lado, se a biblioteca usar uma função que exija o .NET Core (por exemplo, a API da interface do usuário da área de trabalho do Windows), a biblioteca deverá se concentrar no .NET Core:
<TargetFramework>netcoreapp3.0</TargetFramework>
try-convert é uma ferramenta global que você pode
instalar no seu computador e depois ligar da CLI:
C:\> try-convert -p <path to your project>
ou
C:\> try-convert -w <path to your solution>
Como mencionado anteriormente, se a ferramenta try-convert não funcionar no seu caso, aqui estão os materiais sobre como portar o aplicativo manualmente.
VídeoA documentação
Veja também:
7 cursos gratuitos para desenvolvedores