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 tantos desenvolvedores compartilharem suas histórias de migração de aplicativos de desktop (e bibliotecas de controles) para o .NET Core. Ouvimos constantemente histórias de desenvolvedores de desktops .NET do Windows que potencializam seus negócios com o WPF e o Windows Forms, especialmente em cenários em que a área de trabalho brilha, incluindo:
- Aplicativos de formulários densos de interface do usuário sobre dados (FOD)
- Interface do usuário responsiva de baixa latência
- Aplicativos que precisam executar offline / desconectados
- Aplicativos com dependências em drivers de dispositivo personalizados
Este é apenas o começo para o desenvolvimento de aplicativos do Windows no .NET Core. Continue lendo 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 sobre o .NET Core) será o futuro do .NET. Estamos comprometidos em oferecer suporte ao .NET Framework nos próximos anos; no entanto, ele não receberá novos recursos; esses serão adicionados apenas ao .NET Core (e eventualmente 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 do futuro, trouxemos o Windows Forms e o WPF para o .NET Core. Eles ainda permanecerão tecnologias apenas para Windows, porque existem dependências fortemente acopladas às APIs do Windows. Mas o .NET Core, além de ser multiplataforma, possui muitos outros recursos que podem aprimorar os aplicativos de desktop.
Antes de tudo, todos os aprimoramentos de tempo de execução e recursos de idioma serão adicionados apenas ao .NET Core e, no futuro, ao .NET 5. Um bom exemplo aqui é o C # 8 que ficou disponível no .NET Core 3.0. Além disso, as versões .NET Core do Windows Forms e WPF se tornarão parte da plataforma .NET 5. Portanto, ao portar seu aplicativo para o .NET Core hoje, você os prepara para o .NET 5.
Além disso, o .NET Core oferece flexibilidade de implantação para seus aplicativos com novas opções que não estão disponíveis no .NET Framework, como:
- Implantação lado a lado. Agora você pode ter várias versões do .NET Core na mesma máquina e escolher qual versão cada um dos seus aplicativos deve atingir.
- Implantação independente. 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 precisa para executar em qualquer máquina 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 sua implantação independente apenas os assemblies do .NET Core necessários para o seu aplicativo. Dessa forma, todas as peças da plataforma que não são usadas para o seu gabinete serão cortadas.
- Arquivos .exe únicos. Você pode empacotar seu aplicativo e a plataforma .NET Core em um arquivo .exe.
- Desempenho de tempo de execução aprimorado. O .NET Core tem muitas otimizações de desempenho em comparação com o .NET Framework. Quando você pensa sobre o histórico do .NET Core, criado inicialmente para cargas de trabalho da Web e do servidor, ajuda a entender se seu aplicativo pode obter benefícios visíveis das otimizações de tempo de execução. Especificamente, os aplicativos de área de trabalho com grandes dependências nas operações de E / S de arquivo, rede e banco de dados provavelmente verão aprimoramentos no desempenho para esses cenários . Algumas áreas em que você pode não notar muita alteração estão no desempenho da renderização da interface do usuário ou no desempenho da inicialização do aplicativo.
Ao definir as propriedades
<PublishSingleFile> ,
<RuntimeIdentifier> e
<PublishTrimmed> no perfil de publicação, você poderá implantar um aplicativo independente aparado 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á muita diferença entre as versões .NET Framework e .NET Core do WPF e Windows Forms. Uma parte de nosso esforço foi fornecer uma paridade funcional entre essas plataformas na área de desktop e aprimorar a experiência do .NET Core no futuro. Os aplicativos WPF têm suporte total no .NET Core e estão prontos para você usar, enquanto trabalhamos em pequenas atualizações e melhorias. Para o Windows Forms, a parte do tempo de execução é totalmente portada para o .NET Core e a equipe está trabalhando no Windows Forms Designer. Planejamos prepará-lo para o quarto trimestre de 2020 e, por enquanto, você pode conferir a versão Preview do designer no
Visual Studio 16.4 Preview 3 ou posterior. Não se esqueça de marcar a caixa de seleção 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 é limitada por enquanto, pois o trabalho está em andamento.
Quebrando mudanças
Existem algumas
alterações recentes entre o .NET Framework e o .NET Core, mas a maior parte do código relacionado às áreas Windows Forms e WPF foi portada para o Core como está. Se você estava usando componentes como Cliente WCF, Segurança de Acesso ao Código, Domínios de Aplicativos, Interoperabilidade e Comunicação Remota, precisará refatorar seu código se quiser mudar para o .NET Core.
Outra coisa a ter em mente - os caminhos de saída padrão no .NET Core são diferentes dos do .NET Framework, portanto, se você tiver algumas suposições no código sobre a estrutura de arquivos / pastas do aplicativo em execução, provavelmente ocorrerá uma falha no tempo de execução.
Além disso, há alterações em como você configura os recursos do .NET. O .NET Core, em vez do arquivo
machine.config usa o arquivo
<something>.runtimeconfig.json que acompanha um aplicativo e tem o mesmo objetivo geral e informações semelhantes. Algumas configurações, como
system.diagnostics ,
system.net ou
system.servicemodel não são suportadas, portanto, um arquivo de configuração de aplicativo falhará ao carregar se contiver alguma dessas seções. Essa alteração afeta os cenários de rastreamento do sistema,
System.Diagnostics e cliente WCF, que eram normalmente configurados usando a configuração XML anteriormente. No .NET Core, você precisará configurá-los no código. Para alterar comportamentos sem recompilar, considere configurar os tipos de rastreamento e WCF usando valores carregados 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 .
Introdução
Confira estes pequenos tutoriais em vídeo:
Portando do .NET Framework para o .NET Core
Primeiro, execute o
Portability Analyzer e, se necessário, atualize seu código para obter 100% de compatibilidade com o .NET Core. Aqui estão as
instruções sobre o uso do Portability Analyzer . Recomendamos o uso de um controle de origem ou o backup do seu código antes de fazer alterações no aplicativo, caso a refatoração não funcione da maneira desejada e você decida voltar ao seu estado inicial.
Quando seu aplicativo for totalmente compatível com o .NET Core, você estará pronto para portá-lo. Como ponto de partida, você pode experimentar uma ferramenta que criamos para ajudar a automatizar a conversão do (s) seu (s) projeto (s) .NET Framework para .NET Core -
try-convert .
É importante lembrar que esta ferramenta é apenas um ponto de partida em sua jornada para o .NET Core. Também não é um produto 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 sua solução tiver projetos que a ferramenta rejeite ou falhe na conversão, você precisará portar manualmente. Não se preocupe, temos muitos tutoriais sobre como fazê-lo (no final desta seção).
A ferramenta try-convert tentará migrar seus arquivos de projeto no estilo antigo para o novo estilo SDK e redirecionará os projetos aplicáveis para o .NET Core. Para suas bibliotecas, cabe a você fazer uma ligação sobre a plataforma: previsão do tempo que você gostaria de atingir no .NET Core ou no .NET Standard. Você pode especificá-lo em seu 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 segmentação do .NET Standard:
<TargetFramework>netstandard2.1</TargetFramework>
para que eles possam ser usados pelos chamadores que segmentam muitas plataformas .NET diferentes. Por outro lado, se uma biblioteca usa um recurso que requer o .NET Core (como APIs de UI da área de trabalho do Windows), é bom que a biblioteca direcione o .NET Core:
<TargetFramework>netcoreapp3.0</TargetFramework>
try-convert é uma ferramenta global que você pode
instalar em sua máquina e, em seguida, você pode 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 funcionou para você, aqui estão os materiais sobre como portar seu aplicativo manualmente.
VídeosDocumentação