A próxima versão do netcore 3.0 permite executar o wpf no netcore. O procedimento de tradução para um projeto simples leva de um a dois dias. Cada um subsequente é muito mais rápido.
Preparação e conversão de projetos
A primeira etapa da preparação é instalar e executar o Portability Analyzer. Na saída, obtemos uma placa do Excel na qual veremos o quanto nosso código atende aos novos requisitos.
O procedimento para converter projetos antigos foi revertido em várias etapas.
- A Microsoft recomenda atualizar a versão da estrutura para o .NET Framework 4.7.3 para projetos mais antigos.
- Converta a estrutura de projetos antigos em um novo formato. Substitua packages.config por PackageReference.
- Em terceiro lugar, ajuste a estrutura do arquivo csproj para o formato netcore.
Quero agradecer a Emil Yangirov com seu relatório sobre a migração para o netcore, que foi muito útil. Link para o relatório dele.
Acabamos decidindo pular a primeira etapa. A segunda etapa implicou a necessidade de converter mais de 100 projetos. Como esse processo é realizado pode ser lido em detalhes aqui .
Entendemos que a automação não poderia ser evitada. Usou a solução pronta: CsprojToVs2017 . Deixe o nome do projeto não incomodá-lo: o utilitário também converte para o Visual Studio 2019.
O que vai acontecer?
O tamanho dos arquivos csproj diminuirá. Devido a quê? Todos os arquivos conectados com o código fonte sairão do csproj, linhas extras serão removidas etc.
- <Compile Include="Models\ViewModels\HistoryViewModel.cs" /> - <Compile Include="Properties\Settings.Designer.cs"> - <AutoGen>True</AutoGen> - <DependentUpon>Settings.settings</DependentUpon> - <DesignTimeSharedInput>True</DesignTimeSharedInput> - </Compile>
As entradas de biblioteca e subprojeto conectadas serão reduzidas.
- <Reference Include="NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c, processorArchitecture=MSIL"> - <HintPath>..\packages\NLog.4.3.3\lib\net45\NLog.dll</HintPath> - <Private>False</Private> - </Reference> - <ProjectReference Include="..\WpfCommon\WpfCommon.csproj"> - <Project>{7ce118f6-2978-42a7-9e6a-ee5cd3057e29}</Project> - <Name>WpfCommon</Name> - </ProjectReference> + <PackageReference Include="NLog" Version="4.6.7" /> + <ProjectReference Include="..\WpfCommon\WpfCommon.csproj" />
As configurações gerais para vários projetos podem ser realizadas no Directory.BuildProps. Este é um arquivo tão especial que o MsBuild analisa.
Por analogia com .gitignore e .editorconfig, temos um arquivo global com configurações gerais.
Adicionamos as configurações privadas do PropertyGroup para subdiretórios / projetos em arquivos csproj específicos. Detalhes podem ser encontrados aqui.
Dependências
As dependências antigas serão para o quadro de rede. Você precisará encontrar pacotes alternativos ou similares para o nuget. Para muitos projetos, já existe um pacote Nuget que suporta netcore ou netstandard.
Por exemplo, o projeto usou uma versão antiga do DI Unity. Ao mudar para uma nova versão, tive que atualizar usando e corrigir o código em dois ou três lugares.
using Microsoft.Practices.Unity -> using Unity;
E talvez seja suficiente atualizar todas as versões dos pacotes. E por precaução, reinicie o estúdio.
Altere csproj para usar o netcore
Em projetos que usam controles WPF, você precisa alterar o formato para Microsoft.NET.Sdk.WindowsDesktop:
-<?xml version="1.0" encoding="utf-8"?> -<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> - <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" /> - <PropertyGroup/>
+<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> + <PropertyGroup> + <TargetFramework>netcoreapp3.0</TargetFramework> + <AssemblyTitle>MyEnterpriseLibrary</AssemblyTitle> + <Product>MyEnterpriseLibrary</Product> + <OutputPath>..\bin\$(Configuration)\</OutputPath> + <UseWPF>true</UseWPF> + + <GenerateAssemblyInfo>false</GenerateAssemblyInfo> </Project>
Para ClassLibrary, deixe o tipo Microsoft.NET.Sdk:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp3.0</TargetFramework> <AssemblyTitle>MyEnterpriseLibrary</AssemblyTitle> <Product>MyEnterpriseLibrary</Product> <OutputPath>..\bin\$(Configuration)\</OutputPath> </PropertyGroup> </Project>
Talvez, em alguns projetos que usam os controles do Windows Forms, você também precise fazer uma chamada para UseWindowsForms:
<UseWindowsForms>true</UseWindowsForms>
O Csproj mudou sua abordagem para o fluxo de compilação de recursos. Anteriormente, o formato permitia conectar o arquivo aos recursos e Conteúdo,
e até onde.
Agora, se o arquivo estiver em algum tipo de coleção, você precisará removê-lo e incluí-lo apenas no grupo desejado.
Aqui está o código que extrai file.json da coleção None e o conecta à coleção Resource.
<ItemGroup> <None Exclude="file.json" /> <Resource Include="file.json" /> </ItemGroup>
Assim, todos os arquivos que não são de origem devem ser removidos da coleção Nenhum e conectados aos recursos. Por exemplo, assim:
<ItemGroup Condition="'$(UseWPF)' == 'true' And $(UseWindowsForms) != 'true'"> <None Exclude="**\*.xml;**\*.xsl;**\*.xslt;**\*.txt;**\*.bmp;**\*.ico;**\*.cur;**\*.gif;**\*.jpeg;**\*.jpe;**\*.jpg;**\*.png;**\*.dib;**\*.tiff;**\*.tif;**\*.inf;**\*.compositefont;**\*.otf;**\*.ttf;**\*.ttc;**\*.tte" /> <Resource Include="**\*.xml;**\*.xsl;**\*.xslt;**\*.txt;**\*.bmp;**\*.ico;**\*.cur;**\*.gif;**\*.jpeg;**\*.jpe;**\*.jpg;**\*.png;**\*.dib;**\*.tiff;**\*.tif;**\*.inf;**\*.compositefont;**\*.otf;**\*.ttf;**\*.ttc;**\*.tte" /> </ItemGroup>
Algumas linhas terão que ser excluídas, pois derrubam a versão do framework no .net framework 4.0.
Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"
Em alguns lugares após a conversão, permanecerão entradas estranhas que impedem a compilação do projeto. Aqui estão exemplos de tais construções:
- <ItemGroup> - <EmbeddedResource Include="**\*.resx" /> - </ItemGroup> - <Compile Remove="something.cs">
Clientes WCF
Se você usou o WCF, precisará regenerar as ligações. Para fazer isso corretamente, leia aqui: docs.microsoft.com/en-us/dotnet/desktop-wpf/migration/convert-project-from-net-framework#updating-wcf-client-usage
O que não vai decolar?
Stylecop e análise de código.
Alguns de nossos projetos usavam analisadores de código estático. Ao mudar para as edições modernas do MsBuild, o coletor sugere explicitamente o uso de novos analisadores Roslyn em vez dos antigos analisadores de código estático.
Eu tive que traduzir as regras antigas para usar os pacotes Stylecop.Analyzers e FxCop.Analyzers Nuget seguindo este guia da Microsoft. .
Se você possui vários projetos em pastas diferentes (repositório único), é muito mais conveniente colocar a conexão dos analisadores no Build.props e configurá-los com um conjunto de regras uniforme.
Aqui está o que aconteceu:
- <RunCodeAnalysis>true</RunCodeAnalysis> + <PackageReference Include="FxCop.Analyzers" Version="2.9.4" />
Arquivos - Órfãos
O antigo formato csproj implicava conexão explícita de arquivos .cs. Ao mesmo tempo, algumas vezes ao renomear ou refatorar arquivos antigos foram excluídos do csproj, mas não foram excluídos explicitamente do sistema de arquivos. No novo formato csproj, todos os arquivos que estão na pasta do projeto serão selecionados automaticamente, apenas os que não foram excluídos antes. Provavelmente haverá erros neles, apela para classes, métodos e recursos já inexistentes. Isso resultará em erros comuns durante a montagem.
Recursos
Em um dos projetos, foi utilizado o SplashScreen, um dos quais foi selecionado aleatoriamente na inicialização. A instância do SplashScreen foi inicializada com o caminho para o recurso. Por alguma razão, não foi possível ganhar no netcore 3: xinga pela falta de um recurso.
Código que parece funcionar
O código que funcionou no .Net Framework provavelmente também funcionará no netcore. Mas pode haver seções de código às quais o compilador fechou os olhos. Nesse caso, se o código chegar a instruções que não são implementadas no netcore, capturaremos PlatformException.
Para procurar esses locais, existe um analisador especial: github.com/dotnet/platform-compat .
Por que tudo isso se o projeto está funcionando?
Não há muitas vantagens, mas mesmo assim são.
- Seu código receberá todas as otimizações adicionadas ao netcore.
- A velocidade de inicialização do aplicativo aumentará.
- Segmentando versões futuras do C #.
- Tempo de construção reduzido para projetos, graças às novas versões do csproj.
- Embalagem em exe único.
A Microsoft não está empurrando o aplicativo para um novo patamar. No entanto, se o seu aplicativo for um plug-in de outro maior, faz sentido procurar lançamentos futuros, que também podem estar no netcore.
Links úteis