नेटकोर 3.0 की आगामी रिलीज आपको नेटकोर पर wpf चलाने की अनुमति देती है। एक सरल परियोजना के लिए अनुवाद प्रक्रिया में एक से दो दिन लगते हैं। प्रत्येक बाद वाला एक बहुत तेज है।

परियोजनाओं की तैयारी और रूपांतरण

पोर्टेबिलिटी एनालाइजर को स्थापित करने और चलाने के लिए तैयारी में पहला कदम है। आउटपुट में, हमें एक एक्सेल प्लेट मिलती है जिसमें हम देखते हैं कि हमारा कोड नई आवश्यकताओं को कितना पूरा करता है।

पुरानी परियोजनाओं को परिवर्तित करने की प्रक्रिया को कई चरणों में बदल दिया गया।

1. Microsoft पुराने प्रोजेक्ट्स के लिए .Net फ्रेमवर्क 4.7.3 में फ्रेमवर्क संस्करण को अपग्रेड करने की सिफारिश करता है।
2. पुरानी परियोजनाओं की संरचना को एक नए प्रारूप में परिवर्तित करें। PackageReference के साथ package.config को बदलें।
3. तीसरा, csproj फ़ाइल की संरचना को नेटकोर प्रारूप में समायोजित करें।

मैं एमिल यंगिरोव को धन्यवाद देना चाहता हूं कि उन्होंने नेटकोर को प्रवास पर अपनी रिपोर्ट दी, जो बहुत उपयोगी थी। उसकी रिपोर्ट का लिंक।

यह पता चला कि हमने पहले चरण को छोड़ने का फैसला किया है। दूसरे चरण में 100 से अधिक परियोजनाओं को परिवर्तित करने की आवश्यकता निहित है। इस प्रक्रिया को कैसे किया जाता है, यहां विस्तार से पढ़ा जा सकता है ।

हम समझ गए कि स्वचालन से बचा नहीं जा सकता। तैयार समाधान का उपयोग किया: CsprojToVs2017 । प्रोजेक्ट नाम को आपको परेशान न करें: उपयोगिता विजुअल स्टूडियो 2019 के लिए भी परिवर्तित होती है।

क्या होगा?

Csproj फ़ाइलों का आकार घट जाएगा। किस कारण से? सोर्स कोड वाली सभी कनेक्टेड फाइलें csproj छोड़ देंगी, अतिरिक्त लाइनें हटा दी जाएंगी, आदि।

- <Compile Include="Models\ViewModels\HistoryViewModel.cs" /> - <Compile Include="Properties\Settings.Designer.cs"> - <AutoGen>True</AutoGen> - <DependentUpon>Settings.settings</DependentUpon> - <DesignTimeSharedInput>True</DesignTimeSharedInput> - </Compile> 

कनेक्टेड लाइब्रेरी और सबप्रोजेक्ट प्रविष्टियां कम हो जाएंगी।

 - <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" /> 

कई प्रोजेक्ट्स के लिए सामान्य सेटिंग्स को Directory.BuildProps में किया जा सकता है। यह एक ऐसी विशेष फ़ाइल है जो MsBuild में दिखता है।
.Gitignore और .editorconfig के साथ सादृश्य द्वारा, हमारे पास सामान्य सेटिंग्स के साथ एक वैश्विक फ़ाइल है।
हम विशिष्ट csproj फ़ाइलों के लिए उपनिर्देशिका / परियोजनाओं के लिए निजी संपत्ति समूह सेटिंग्स जोड़ते हैं। विवरण यहाँ पाया जा सकता है।

पर निर्भर करता है

नेटफ्रेमवर्क के लिए पुरानी निर्भरता होगी। आपको नगेट के लिए एक वैकल्पिक या समान पैकेज खोजना होगा। कई परियोजनाओं के लिए, पहले से ही एक Nuget पैकेज है जो netcore या netstandard का समर्थन करता है।

उदाहरण के लिए, प्रोजेक्ट ने DI यूनिटी के पुराने संस्करण का उपयोग किया। एक नए संस्करण पर स्विच करते समय, मुझे दो या तीन स्थानों में कोड का उपयोग करके अद्यतन करना था।

 using Microsoft.Practices.Unity -> using Unity; 

और शायद यह पैकेज के सभी संस्करणों को अपग्रेड करने के लिए पर्याप्त होगा। और बस मामले में, स्टूडियो को पुनरारंभ करें।

नेटकोर का उपयोग करने के लिए csproj बदलें

WPF नियंत्रण का उपयोग करने वाली परियोजनाओं में, आपको 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> + <!--    assemblyinfo    ,    --> + <GenerateAssemblyInfo>false</GenerateAssemblyInfo> </Project> 

ClassLibrary के लिए, बस 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> 

शायद, Windows Forms नियंत्रणों का उपयोग करने वाली कुछ परियोजनाओं में, आपको UseWindowsForms पर एक कॉल चिपका देना होगा:

 <UseWindowsForms>true</UseWindowsForms> 

Csproj ने संसाधन संकलन प्रवाह के लिए अपना दृष्टिकोण बदल दिया है। पहले, प्रारूप ने आपको फ़ाइल को संसाधनों और सामग्री दोनों से जोड़ने की अनुमति दी थी,
और जहां भी।

अब, यदि फ़ाइल किसी प्रकार के संग्रह में है, तो आपको इसे से निकालने की आवश्यकता है, और उसके बाद ही इसे वांछित समूह में शामिल करें।
यहां वह कोड है जो फ़ाइल.जॉन को किसी भी संग्रह से नहीं खींचता है और इसे संसाधन संग्रह से जोड़ता है।

 <ItemGroup> <None Exclude="file.json" /> <Resource Include="file.json" /> </ItemGroup> 

तदनुसार, सभी फाइलें जो स्रोत नहीं हैं, उन्हें किसी भी संग्रह से नहीं हटाया जाना चाहिए और संसाधनों से जुड़ा होना चाहिए। उदाहरण के लिए, इस तरह:

 <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> 

कुछ लाइनों को हटाना होगा, क्योंकि वे .net फ्रेमवर्क 4.0 पर फ्रेमवर्क संस्करण को खटखटाते हैं।

  Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" 

रूपांतरण के बाद कुछ स्थानों पर, अजीब प्रविष्टियाँ बनी रहेंगी जो परियोजना को संकलित करने से रोकती हैं। यहाँ इस तरह के निर्माण के उदाहरण हैं:

 - <ItemGroup> - <EmbeddedResource Include="**\*.resx" /> - </ItemGroup> - <Compile Remove="something.cs"> 

WCF ग्राहक

यदि आपने डब्ल्यूसीएफ का उपयोग किया है, तो आपको बाइंडिंग को फिर से बनाना होगा। इसे सही तरीके से यहां कैसे पढ़ा जा सकता है: docs.microsoft.com/en-us/dotnet/desktop-wpf/migration/convert-project-from-net-framework#updating-wcf-client-usage

क्या नहीं ले जाएगा?

स्टाइलकॉप और कोड विश्लेषण।

हमारे कुछ प्रोजेक्ट्स में स्टैटिक कोड एनालाइजर का इस्तेमाल किया गया। आधुनिक MsBuild संस्करणों में स्विच करते समय, कलेक्टर स्पष्ट रूप से पुराने स्टैटिक कोड एनालाइज़र के बजाय नए Roslyn analyzers का उपयोग करने का सुझाव देता है।

मुझे इस Microsoft गाइड के बाद Stylecop.Analyzers और FxCop.Analyzers Nuget पैकेज का उपयोग करने के लिए पुराने नियमों का अनुवाद करना था । ।
यदि आपके पास विभिन्न फ़ोल्डरों (मोनो-रिपॉजिटरी) में कई परियोजनाएं हैं, तो Build.props में analyzers के कनेक्शन को बाहर करना और उन्हें एक समान नियम के साथ कॉन्फ़िगर करना अधिक सुविधाजनक है।

यहाँ क्या हुआ:

 - <RunCodeAnalysis>true</RunCodeAnalysis> + <PackageReference Include="FxCop.Analyzers" Version="2.9.4" /> 

फाइलें - अनाथ

पुराने csproj प्रारूप में .cs फ़ाइलों का स्पष्ट कनेक्शन निहित है। उसी समय, कभी-कभी पुरानी फ़ाइलों का नाम बदलने या उन्हें हटाने के बाद csproj से हटा दिया जाता था, लेकिन उन्हें फ़ाइल सिस्टम से स्पष्ट रूप से हटाया नहीं गया था। नए csproj प्रारूप में, परियोजना फ़ोल्डर में मौजूद सभी फाइलें स्वचालित रूप से उठाई जाएंगी, बस जो पहले नहीं हटाई गई हैं। सबसे अधिक संभावना है कि उनमें त्रुटियां होंगी, पहले से मौजूद गैर-मौजूद वर्गों, विधियों, संसाधनों से अपील की जाती है। यह विधानसभा के दौरान सामान्य त्रुटियों का परिणाम देगा।

साधन

एक परियोजना में, स्प्लैशस्क्रीन का उपयोग किया गया था, जिनमें से एक को स्टार्टअप पर यादृच्छिक रूप से चुना गया था। स्प्लैशस्क्रीन इंस्टेंस को संसाधन के पथ के साथ आरंभ किया गया था। किसी कारण से, नेटकोर 3 पर जीतना संभव नहीं था: संसाधन की कमी पर शपथ लेता है।

कोड जो काम करने लगता है

.Net फ्रेमवर्क में काम करने वाला कोड नेटकोर में भी काम करने की संभावना है। लेकिन कोड के कुछ खंड हो सकते हैं जो संकलक ने अपनी आँखें बंद कर ली हैं। इस स्थिति में, यदि कोड उन निर्देशों को जाता है जो नेटकोर में कार्यान्वित नहीं किए जाते हैं, तो हम PlatformException को पकड़ लेंगे।

ऐसे स्थानों की खोज करने के लिए, एक विशेष विश्लेषक है: github.com/dotnet/platform-compat ।

यह सब क्यों है अगर परियोजना काम कर रही है?

कई फायदे नहीं हैं, लेकिन फिर भी, वे हैं।

• आपके कोड को netcore में जोड़े गए सभी अनुकूलन प्राप्त होंगे।
• एप्लिकेशन लॉन्च की गति बढ़ जाएगी।
• C # के भावी संस्करणों को लक्षित करना।
• Csproj के नए संस्करणों के लिए परियोजनाओं के निर्माण के लिए कम समय।
• एकल exe में पैकिंग।

Microsoft एप्लिकेशन को नए फ़ुटिंग पर नहीं धकेल रहा है। फिर भी, यदि आपका आवेदन दूसरे बड़े का एक प्लगइन है, तो यह भविष्य के रिलीज पर लक्ष्य बनाने के लिए समझ में आता है, जो कि नेटकोर पर भी हो सकता है।

उपयोगी लिंक

• docs.microsoft.com/ru-ru/dotnet/desktop-wpf/migration/convert-project-from-net-framework
• docs.microsoft.com/ru-ru/dotnet/core/porting/winforms
• devblogs.microsoft.com/dotnet/migrating-a-sample-wpf-app-to-net-core-3-part-1
• devblogs.microsoft.com/dotnet/migrating-a-sample-wpf-app-to-net-core-3-part-2
• devblogs.microsoft.com/dotnet/how-to-port-desktop-applications-to-net-core-3-0
• www.nuget.org/packages/Microsoft.Windows.Compatibility
• www.youtube.com/watch?v=jLBUk1hvLoU