يسمح لك الإصدار القادم من netcore 3.0 بتشغيل wpf على netcore. تستغرق إجراءات الترجمة لمشروع بسيط من يوم إلى يومين. كل واحد لاحق هو أسرع بكثير.
إعداد وتحويل المشاريع
الخطوة الأولى في الإعداد هي تثبيت وتشغيل Portability Analyzer. في المخرجات ، نحصل على لوحة Excel سنرى فيها مدى تلبية الكود الخاص بنا للمتطلبات الجديدة.
تم تشغيل الإجراء لتحويل المشاريع القديمة على عدة مراحل.
- توصي Microsoft بترقية إصدار Framework إلى .Net Framework 4.7.3 للمشاريع القديمة.
- تحويل هيكل المشاريع القديمة إلى تنسيق جديد. استبدال الحزم. تكوين مع PackageReference.
- ثالثًا ، قم بضبط بنية ملف csproj إلى تنسيق netcore.
أود أن أشكر إميل يانجيروف على تقريره عن الهجرة إلى netcore ، والذي كان مفيدًا للغاية. رابط لتقريره.
اتضح أننا قررنا تخطي المرحلة الأولى. تتضمن المرحلة الثانية الحاجة إلى تحويل أكثر من 100 مشروع. يمكن قراءة كيفية إجراء هذه العملية بالتفصيل هنا .
لقد فهمنا أنه لا يمكن تجنب التشغيل الآلي. استخدم الحل الجاهز : CsprojToVs2017 . اسمح للمشروع بعدم إزعاجك: تقوم الأداة المساعدة أيضًا بتحويل Visual Studio 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 ، لدينا ملف عمومي ذو إعدادات عامة.
نضيف إعدادات PropertyGroup الخاصة للدلائل / المشاريع إلى ملفات csproj محددة. التفاصيل يمكن العثور عليها هنا.
اعتمادا على
سوف تكون التبعيات القديمة من أجل netframework. سيكون عليك العثور على حزم بديلة أو مشابهة لـ nuget. بالنسبة للعديد من المشاريع ، يوجد بالفعل حزمة Nuget تدعم netcore أو netstandard.
على سبيل المثال ، استخدم المشروع نسخة قديمة من DI Unity. عند التبديل إلى إصدار جديد ، اضطررت إلى تحديث استخدام وإصلاح التعليمات البرمجية في مكانين أو ثلاثة.
using Microsoft.Practices.Unity -> using Unity;
وربما ستكون كافية لترقية جميع إصدارات الحزم. وفقط في حالة إعادة تشغيل الاستوديو.
تغيير csproj لاستخدام netcore
في المشروعات التي تستخدم عناصر التحكم 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> + + <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 قد غيرت نهجها لتدفق تجميع الموارد. في السابق ، سمح لك التنسيق بتوصيل الملف بكل من الموارد والمحتوى ،
وحتى أين.
الآن ، إذا كان الملف في مجموعة من الأنواع ، فأنت بحاجة إلى إزالته منه ، وبعد ذلك فقط تدرجه في المجموعة المطلوبة.
هنا هو الكود الذي يسحب file.json من مجموعة None ويربطه بمجموعة الموارد.
<ItemGroup> <None Exclude="file.json" /> <Resource Include="file.json" /> </ItemGroup>
وفقًا لذلك ، يجب إزالة جميع الملفات غير المصدر من مجموعة None وتوصيلها بالموارد. على سبيل المثال ، مثل هذا:
<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 framework 4.0.
Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"
في بعض الأماكن بعد التحويل ، ستبقى إدخالات غريبة تمنع تجميع المشروع. فيما يلي أمثلة على هذه الإنشاءات:
- <ItemGroup> - <EmbeddedResource Include="**\*.resx" /> - </ItemGroup> - <Compile Remove="something.cs">
عملاء WCF
إذا كنت تستخدم WCF ، فستضطر إلى تجديد الروابط. يمكن قراءة كيفية القيام بذلك بشكل صحيح هنا: docs.microsoft.com/en-us/dotnet/desktop-wpf/migration/convert-project-from-net-framework#updating-wcf-client-usage
ما لن تقلع؟
Stylecop وتحليل الرمز.
بعض مشاريعنا تستخدم محللات الكود الثابت. عند التبديل إلى إصدارات MsBuild الحديثة ، يقترح المجمع صراحة استخدام أجهزة تحليل Roslyn جديدة بدلاً من أجهزة تحليل الشفرات الثابتة القديمة.
اضطررت إلى ترجمة القواعد القديمة لاستخدام حزم Stylecop.Analyzers و FxCop.Analyzers Nuget باتباع دليل Microsoft هذا. .
إذا كان لديك العديد من المشاريع في مجلدات مختلفة (مستودع أحادي) ، فمن الملائم أكثر وضع اتصال المحللين في Build.props وتكوينها باستخدام مجموعة قواعد موحدة.
إليك ما حدث:
- <RunCodeAnalysis>true</RunCodeAnalysis> + <PackageReference Include="FxCop.Analyzers" Version="2.9.4" />
ملفات - الأيتام
يتضمن تنسيق csproj القديم اتصالًا صريحًا بملفات .cs. في الوقت نفسه ، أحيانًا عند حذف أو إعادة تسمية الملفات القديمة من csproj ، لكن لم يتم حذفها بشكل صريح من نظام الملفات. في تنسيق csproj الجديد ، سيتم تلقائيًا التقاط جميع الملفات الموجودة في مجلد المشروع ، فقط الملفات التي لم يتم حذفها من قبل. على الأرجح سيكون هناك أخطاء فيها ، وتناشد فئات وأساليب وموارد غير موجودة بالفعل. سيؤدي ذلك إلى أخطاء شائعة أثناء التجميع.
موارد
في أحد المشروعات ، تم استخدام SplashScreen ، تم اختيار أحدهما عشوائيًا عند بدء التشغيل. تمت تهيئة مثيل SplashScreen باستخدام المسار إلى المورد. لسبب ما ، لم يكن من الممكن الفوز على netcore 3: أقسم على عدم وجود مورد.
الكود الذي يبدو أنه يعمل
من المحتمل أن تعمل التعليمات البرمجية التي عملت في .Net Framework في netcore أيضًا. ولكن قد يكون هناك أقسام من التعليمات البرمجية التي أغلق المترجم عينيه بها. في هذه الحالة ، إذا حصلت التعليمة البرمجية على تعليمات غير مطبقة في netcore ، فسنلحق PlatformException.
من أجل البحث عن مثل هذه الأماكن ، يوجد محلل خاص: github.com/dotnet/platform-compat .
لماذا كل هذا إذا كان المشروع يعمل؟
ليست هناك العديد من المزايا ، ولكن مع ذلك ، فهي كذلك.
- ستتلقى الشفرة الخاصة بك جميع التحسينات التي تمت إضافتها إلى netcore.
- سوف تزيد سرعة إطلاق التطبيق.
- استهداف الإصدارات المستقبلية من C #.
- تقليل وقت البناء للمشاريع بفضل الإصدارات الجديدة من csproj.
- التعبئة في واحدة إكس.
لا تدفع Microsoft التطبيق إلى مستوى جديد. ومع ذلك ، إذا كان التطبيق الخاص بك هو مكون إضافي من تطبيق آخر أكبر ، فمن المنطقي أن تستهدف الإصدارات المستقبلية ، والتي قد تكون أيضًا على netcore.
روابط مفيدة