ما الذي يجب التحقّق منه قبل ترحيل .NET Framework إلى .NET - قائمة تحقّق عمليّة لما قبل الترحيل

تنزيل قائمة التحقّق بصيغة Excel مع أوراق باللغتين اليابانيّة والإنجليزيّة

تغيير TargetFramework إلى net10.0، وتحديث بضع حزم NuGet، وإعلان اكتمال الترحيل، ستكون قصّة هادئة جدّاً.

في المشاريع الحقيقيّة، عادةً ما لا تكون الأمور بهذا الهدوء.

تحمل أنظمة .NET Framework القديمة في كثير من الأحيان افتراضات لا يفكّر فيها أحد إلى أن يبدأ الترحيل: System.Web، و WCF، و Web Forms، و packages.config القديمة، و web.config.install.xdt، و DLL أصليّة، و COM أو ActiveX، وعناصر تحكّم خارجيّة لا تعمل إلّا في وقت التصميم، وافتراضات x86 خفيّة، واستخدام ResX المعتمد على المصمّم، ومُسلسِلات قديمة.

ولذلك فإنّ الجزء الأهمّ من ترحيل .NET Framework إلى .NET غالباً ما لا يكون مرحلة التنفيذ. بل هو مرحلة الجرد قبل بدء التنفيذ.
إذا تمكّنت من تقسيم المشكلة إلى مسارات واضحة في وقت مبكّر، فإنّ الترحيل يتوقّف عن كونه مقامرة كبيرة واحدة ويبدأ بالتحوّل إلى سلسلة من القرارات المدروسة.

يستهدف هذا المقال تطبيقات الأعمال القائمة على .NET Framework 4.x التي يجري النظر في ترحيلها إلى .NET الحالي. الأهداف الرئيسيّة هي:

• مكتبات الفئات (class libraries)
• تطبيقات وحدة التحكّم (console applications)
• Windows services
• تطبيقات WinForms / WPF
• تطبيقات ASP.NET Framework، بما في ذلك MVC و Web API و Web Forms
• التطبيقات التي تستخدم WCF
• التطبيقات التي تستخدم EF6

النقطة الزمنيّة لهذا المقال هي 15 مارس 2026. الجداول الزمنيّة للدعم وإرشادات الأدوات الرسميّة قد تتغيّر، لذا إذا كنت تقرأ هذا في وقت لاحق، فتحقّق من وثائق Microsoft الحاليّة أيضاً.

1. النسخة المختصرة

فيما يلي الاستنتاجات التي يصعب تجنّبها في الممارسة العمليّة.

• نظّف جانب .NET Framework أوّلاً. إرشادات Microsoft الرسميّة لما قبل الترحيل تدفع في الاتّجاه نفسه: ارفع target Framework إلى 4.7.2 أو أحدث، واتّجه نحو PackageReference، واتّجه نحو مشاريع SDK-style، وحدّث التبعيّات قبل محاولة النقل الفعليّ.
• يحدّد نموذج التطبيق الصعوبة أكثر ممّا يحدّدها حجم الكود الإجماليّ. مكتبات الفئات وأدوات وحدة التحكّم غالباً ما تكون قابلة للإدارة. أمّا ASP.NET Framework و Web Forms و خوادم WCF و Workflow Foundation فتميل إلى أن تكون أثقل بكثير.
• يمكن نقل WinForms و WPF إلى .NET مع البقاء حصراً على Windows. إذا كان هذا التوقّع خاطئاً، فإنّ الفِرَق تكتشف في الغالب متأخّراً جدّاً أنّ التطبيق المرحَّل لا يزال غير قادر على الانتقال إلى Linux containers أو إلى استضافة عابرة للأنظمة الأساسيّة.
• ترحيل ASP.NET Framework إلى ASP.NET Core هو فعليّاً ترحيل معماريّ. قد تنتقل الأنظمة الصغيرة دفعةً واحدة في بعض الأحيان، لكنّ أنظمة الإنتاج الأكبر تكون أكثر أماناً مع الترحيل التدريجيّ.
• WCF و EF6 لا يجب دائماً نقلهما وفق الجدول الزمنيّ نفسه الذي يتّبعه runtime. WCF clients لديها حزم مدعومة على .NET الحديث، ويمكن أحياناً إبقاء EF6 في مكانه بينما ينتقل runtime أوّلاً ويأتي EF Core لاحقاً.
• إنشاء AppDomain و .NET Remoting و CAS و COM+ و Workflow Foundation والاعتماد على BinaryFormatter كلّها أعلام حمراء. إذا اكتشفتها متأخّراً، فإنّ الجهد عادةً ما ينفجر في وقت متأخّر.
• packages.config، و install.ps1، و XDT transforms، و أصول content، و DLL أصليّة، و COM أو ActiveX، وافتراضات x86 الخفيّة هي بالضبط من النوع الذي لا يزال يفشل بعد build ناجح، خصوصاً في وقت التشغيل أو في وقت التصميم.
• اعتباراً من مارس 2026، تُعدّ .NET 10 هي LTS الحاليّة. بالنسبة لمناطق الهبوط الجديدة للترحيل، فإنّ LTS الحاليّة عادةً ما تكون الإعداد الافتراضيّ النظيف.
• الترحيل بدون اختبارات وقياسات أساسيّة وتفكير في التراجع أمر خطير. عمليّاً، الترحيل أقلّ ما يكون عن كتابة التغييرات وأكثر ما يكون عن جعل الافتراضات الخفيّة مرئيّة واحداً تلو الآخر.

2. قرّر هل ينبغي نقل هذا النظام الآن

القرار الأوّل ليس “كيف نرحّل؟”
القرار الأوّل هو هل ينبغي نقل هذا التطبيق المحدّد الآن من الأساس.

إذا بقي ذلك السؤال غامضاً، فإنّ الفِرَق غالباً ما ينتهي بها الأمر إلى ترحيل منطقيّ تقنيّاً لكنّه ثقيل جدّاً على الأعمال، أو العكس: نظام يجب نقله بوضوح يتأخّر مدّةً طويلة جدّاً لأنّ المشكلة لم تُؤطَّر بوضوح.

2.1 البقاء على .NET Framework يمكن أن يكون اختياراً عقلانيّاً

.NET Framework 4.8.1 يبقى مدعوماً طالما يعمل على إصدارات Windows المدعومة. هذا يعني أنّ الموقف ليس ببساطة “كلّ شيء يجب أن ينتقل إلى .NET الحديث فوراً وإلّا فهو غير آمن تلقائيّاً”.

لكنّ البقاء له أيضاً قيود واضحة:

• تظلّ مقتصراً على Windows
• تبقى نماذج الخوادم والتطبيقات القديمة في مكانها
• يصعب الاستفادة من تحسينات runtime واللغة والأدوات الأحدث في .NET
• ينحرف النظام أكثر فأكثر عن الافتراضات الحاليّة للسحابة و containers و CI/CD

من ناحية أخرى، يمكن أن يكون البقاء على .NET Framework 4.8.1 لبعض الوقت قراراً طبيعيّاً جدّاً إذا كان التطبيق يعتمد بشكل كبير على أمور مثل:

• مساحة واجهة Web Forms كبيرة
• متطلّبات صارمة لتوافق خادم WCF
• استخدام عميق لـ Workflow Foundation أو COM+
• مكوّنات خارجيّة لوقت التصميم غير جاهزة لـ .NET الحديث
• قيود تجاريّة لا تتحمّل تغييراً سلوكيّاً واسع النطاق

2.2 تهمّ منطقة الهبوط أكثر من الرغبة في الترحيل

من المفيد فصل خيارات منطقة الهبوط الرئيسيّة في وقت مبكّر.

السؤال الرئيسيّ ليس “هل نريد الترحيل؟”
بل هو أين بالضبط نريد أن يهبط النظام بعد الترحيل؟

3. أربعة قرارات يجب اتّخاذها قبل أوّل مهمّة ترحيل

3.1 اختر إصدار .NET المستهدف

في وقت كتابة هذا المقال، .NET 10 هي LTS الحاليّة.
وفي الوقت نفسه، يُتوقَّع أن يصل كلٌّ من .NET 8 LTS و .NET 9 STS إلى نهاية الدعم في 10 نوفمبر 2026.

لذلك إذا كنت تبدأ جهد ترحيل جديداً الآن، فإنّ الخيار الافتراضيّ عادةً هو LTS الحاليّة ما لم يكن هناك سبب قويّ لعدم ذلك.

تبدو تلك القاعدة العمليّة عادةً هكذا:

• بالنسبة لترحيل صغير، اهبط مباشرةً على LTS الحاليّة
• بالنسبة لنظام أساسيّ طويل العمر، تبقى LTS الحاليّة هي الخطّ الأساس الأكثر أماناً
• إذا كنت تريد LTS السابقة بسبب قيود التبعيّات، فاتّخذ القرار وأمامك تواريخ الدعم الفعليّة

3.2 قرّر هل البقاء على Windows فقط مقبول لمنطقة الهبوط

هذا القرار يغيّر الجرد بأكمله.

• إذا كان البقاء على Windows فقط مقبولاً، فيمكنك في الغالب اتّخاذ مسار عمليّ: انقل runtime أوّلاً وأبقِ WPF و WinForms و Windows APIs المختارة في مكانها للوقت الراهن.
• إذا كانت العبور المستقبليّ للأنظمة الأساسيّة مهمّاً، فإنّ APIs المختصّة بـ Windows تحتاج إلى الظهور مبكّراً: System.Drawing.Common، والوصول إلى registry، و WMI، و Event Log، و Windows Service APIs، و COM، و Office Interop، والمناطق المماثلة.

إذا لم تقرّر هذا في وقت مبكّر، فإنّ المشروع غالباً ما يُجَرّ في اتّجاهَين في منتصف الطريق.

3.3 اختر بين الترحيل دفعةً واحدة والترحيل التدريجيّ

بشكل عامّ، تميل عمليّات الترحيل إلى الوقوع في ثلاثة أنماط:

• ترحيل قريب من in-place
• ترحيل side-by-side حيث يعمل القديم والجديد بالتوازي
• ترحيل تدريجيّ حسب route أو خدمة أو مكتبة

هذا مهمّ بشكل خاصّ لأنظمة ASP.NET Framework. إرشادات Microsoft الرسميّة تصف صراحةً الترحيل التدريجيّ. إذا كان وقت التشغيل يهمّ، أو كانت التبعيّات المحيطة واسعة، أو كانت مساحة الميزات كبيرة، فمن الأكثر أماناً عادةً افتراض مسار تدريجيّ من البداية.

3.4 قرّر ما هو خارج النطاق عمداً

تصبح عمليّات الترحيل خطرة عندما يُحزَم الكثير من التغييرات الكبيرة معاً.

التركيبات التالية ثقيلة بشكل خاصّ:

• .NET Framework إلى .NET
• ASP.NET Framework إلى ASP.NET Core
• EF6 إلى EF Core
• استضافة Windows Server إلى Linux containers
• تغييرات منصّة المصادقة
• تغييرات منصّة التسجيل والمراقبة
• ترحيل قواعد البيانات

حتّى لو كانت كلّ هذه الأمور قد تكون ضروريّة في النهاية، فإنّها لا تحتاج جميعاً إلى أن تكون في مرحلة الترحيل نفسها. التسلسل الأكثر استقراراً غالباً ما يكون:

1. حدِّث runtime وبنية المشروع أوّلاً
2. انقل نموذج التطبيق بعد ذلك
3. حدِّث ORM والمصادقة وشكل السحابة والمراقبة لاحقاً

4. هيّئ الأرضيّة قبل النقل

إرشادات Microsoft لما قبل الترحيل عمليّة بشكل منعش. الفكرة بسيطة:
اسحب مشروع .NET Framework الحاليّ نحو اتّفاقيّات أكثر حداثة قبل أن تطلب منه عبور حدود runtime.

4.1 انقل جانب Framework إلى 4.7.2 أو أحدث أوّلاً

توصي الإرشادات الرسميّة باستهداف .NET Framework 4.7.2 أو أحدث قبل النقل. ذلك يجعل من الأسهل الابتعاد عن افتراضات APIs القديمة والتوافق بشكل أفضل مع مشاركة .NET Standard 2.0.

عمليّاً، إذا تمكّنت من الوصول إلى 4.8.1، فهذا غالباً ما يكون الخطّ الأساس الأكثر وضوحاً.

• إنّها نقطة الاستقرار النهائيّة الطبيعيّة على جانب Framework
• يسهل شرح وضع الدعم
• تساعد في فصل “هذه ضوضاء Framework القديم” عن “هذه مشكلة توافق حقيقيّة في .NET الحديث”

4.2 اتّجه نحو PackageReference

توصي إرشادات النقل الخاصّة بـ Microsoft أيضاً بنقل package references نحو PackageReference.

ذلك يساعد لأنّ:

• package references تقيم في csproj
• تصبح التبعيّات الانتقاليّة أسهل في الفهم
• يقترب سلوك restore من توقّعات .NET الحديثة
• تصبح سير عمل CLI و CI أكثر نظافة

لكنّ هذه الخطوة ليست مجرّد تحويل تنسيق. وثائق NuGet تشير إلى قيود حقيقيّة عند الانتقال من packages.config:

• مسار الترحيل المدمج في Visual Studio لا ينطبق على مشاريع ASP.NET
• الحزم التي تعتمد على install.ps1 أو uninstall.ps1 قد لا تتصرّف بالطريقة نفسها
• قد يتمّ تجاهل بعض أصول content
• لا يتمّ تطبيق XDT transforms مثل web.config.install.xdt
• قد تُحلّ تخطيطات الحزم القديمة بشكل مختلف

أنظمة ASP.NET الكلاسيكيّة معرّضة بشكل خاصّ للمفاجآت هنا لأنّ تثبيت الحزم كان في الغالب يعيد كتابة web.config خلف الكواليس.

4.3 اتّجه نحو مشاريع SDK-style

الانتقال إلى ملفّات مشاريع SDK-style يدفع أيضاً بشكل أسرع ممّا تتوقّع كثير من الفِرَق.

عادةً ما يعني ذلك:

• csproj أبسط بكثير
• توافق أفضل مع PackageReference
• multi-targeting أسهل
• سير عمل dotnet build و dotnet test و dotnet publish أسهل
• اختلافات هيكليّة أقلّ متبقّية لنقل runtime الفعليّ

بمعنى آخر، csproj بأسلوب قديم زائد إدارة NuGet قديمة زائد قفزة runtime غالباً ما يكون انحرافاً كبيراً جدّاً في وقت واحد.

4.4 حدِّث التبعيّات قبل النقل الفعليّ

توصي الإرشادات الرسميّة أيضاً بنقل التبعيّات نحو أحدث الإصدارات العمليّة، ومن الناحية المثاليّة الإصدارات التي تدعم بالفعل .NET Standard أو .NET الحديث.

هذا مهمّ لأنّه يكشف عن العوائق الحقيقيّة في وقت مبكّر:

• أيّ الحزم يمكن أن تعمل بالفعل على .NET الحديث
• أيّ الحزم هي الطرق المسدودة الفعليّة
• أيّ المكتبات المشتركة يمكنها واقعيّاً الانتقال إلى netstandard2.0
• أيّ أجزاء من الترحيل اللاحق يمكن أن تركّز على الكود بدلاً من علم آثار التبعيّات

4.5 تحقّق من الافتراضات الكامنة وراء إرشادات أدوات Microsoft الحاليّة

اعتباراً من مارس 2026، تركّز إرشادات الترحيل من Microsoft بشكل أكبر على سير عمل GitHub Copilot app modernization.
هذا يعني أنّ محادثة الأدوات لم تعد تتعلّق فقط بمساعد ترحيل واحد. إنّها تتعلّق بالتقييم والتخطيط وتغييرات الكود والتحقّق كتدفّق موجَّه واحد.

لكنّ الافتراضات الرسميّة لا تزال مهمّة. الإرشادات الحاليّة مكتوبة حول:

• Visual Studio 2026 أو خطّ Visual Studio 2022 المدعوم حاليّاً
• GitHub Copilot
• قواعد كود C#

هذا مهمّ لأنّه يغيّر مستوى الأتمتة الذي ينبغي أن يتوقّعه الفريق. كما يساعد في الكشف مبكّراً عمّا إذا كان الفريق يحتاج إلى ترقيات IDE، أو تحديثات الإضافات، أو ما إذا كان حلّ يحتوي على VB.NET فيه ينبغي أن يفترض المزيد من العمل اليدويّ.

5. قدّر الصعوبة حسب نوع المشروع، لا حسب “ترحيل” عامّ واحد

كثيراً ما يتحدّث الناس عن “ترحيل .NET Framework إلى .NET” كما لو كان نقلة واحدة.
عمليّاً، كلّ نوع مشروع لعبة مختلفة.

5.1 خريطة صعوبة تقريبيّة

5.2 تعتمد مكتبات الفئات على ما إذا كانت قابلة للمشاركة حقّاً

غالباً ما تكون مكتبات الفئات الجزء الأسهل ظاهراً، لكن فقط إذا كانت مفصولة فعلاً مثل المكتبات.

ترتفع الصعوبة بسرعة عندما تلمس المكتبة أموراً مثل:

• System.Web
• HttpContext.Current
• أنواع WPF أو WinForms في APIs العامّة
• registry أو WMI أو Event Log أو Windows APIs أخرى
• افتراضات AppDomain أو Remoting

أسهل المكتبات للنقل هي تلك التي تحتوي حقّاً على قواعد العمل والعقود والحسابات والتحويلات بدلاً من سلوك نموذج التطبيق.

5.3 ينتقل WinForms و WPF، لكنّهما يبقيان مقتصرَين على Windows

يمكن نقل WinForms و WPF إلى .NET، لكنّهما يبقيان أُطُر عمل مقتصرة على Windows.

هذا يعني أنّ الترحيل لا يزال يمكن أن يجلب فوائد حقيقيّة:

• ميزات runtime واللغة الحاليّة
• بنية مشروع وسير عمل CI/CD أكثر حداثة
• تبعيّات وسير عمل نشر أفضل

لكنّ بعض الأمور لا تختفي بطريقة سحريّة:

• افتراضات الاستضافة المختصّة بـ Windows
• مشاكل توافق المصمّم وعناصر التحكّم الخارجيّة
• التبعيّة على ActiveX و COM و DLL أصليّة

هناك أيضاً فئة محدّدة من المخاطر حول السلوك المتعلّق بـ BinaryFormatter، خصوصاً عندما يتمّ إشراك الحافظة أو السحب والإفلات أو ResX أو سلسلة المصمّم لأنواع مخصّصة.

5.4 ASP.NET Framework ليس مجرّد نقلة runtime

ترحيل ASP.NET Framework إلى ASP.NET Core ليس مجرّد تمرين لإعادة التسمية. وثائق Microsoft تعامله صراحةً على أنّه غير تافه لأنّ المعماريّة تتحوّل:

• نموذج الاستضافة
• خطّ أنابيب middleware
• معالجة الطلبات
• الجلسة والتخزين المؤقّت
• المصادقة والتفويض
• الإعدادات
• dependency injection
• التسجيل والمراقبة

هذا يعني أنّ الأسئلة الحقيقيّة هي:

• أيّ routes أو endpoints يمكن نقلها أوّلاً
• ما إذا كان من الممكن إزالة System.Web من المكتبات المشتركة
• كيف ستتراصف المصادقة والجلسة ومعالجة الأخطاء والتسجيل أثناء الانتقال
• ما إذا كان الترحيل بدون توقّف أو الترحيل التدريجيّ منخفض المخاطر مطلوباً

5.5 يجب التعامل مع Web Forms كمشكلة تقسيم مسؤوليّات

Web Forms ليست نموذج التطبيق نفسه الذي يتّبعه ASP.NET Core.
لذا فإنّ من الأكثر أماناً عادةً عدم تقدير الأمر كما لو كان من الممكن نقل أصول UI ببساطة عبر الحدود.

النقلة الأولى الأكثر واقعيّة غالباً ما تكون:

• تقسيم منطق الشاشة عن منطق العمل
• تفكيك المسؤوليّات المدفونة في Page و UserControl و ViewState
• نقل طبقات العمل والبيانات إلى مكتبات مشتركة
• إعادة بناء UI في نموذج مختلف مثل MVC أو Razor Pages أو Blazor

بمعنى آخر، ترحيل Web Forms عادةً ما يدور حول استخراج المسؤوليّات قبل ترحيل runtime.

5.6 تعامل مع WCF clients و WCF servers بشكل منفصل

هذا الفصل مهمّ.

WCF client

لدى WCF clients حزم مدعومة على .NET الحديث، لذا فإنّ استدعاء خدمة WCF موجودة يمكن أن يكون أقلّ دراميّة بكثير ممّا يتوقّعه الناس.

WCF server

استضافة الخدمة شيء مختلف. إرشادات Microsoft عادةً ما تقود إلى أحد المسارَين:

• CoreWCF للحصول على توافق أقوى مع WCF clients الحاليّة
• gRPC أو نموذج HTTP/RPC حديث آخر إذا كانت إعادة التصميم مقبولة

CoreWCF ليست نسخة كاملة قابلة للإسقاط لكلّ ما كان WCF server يقدّمه. إنّها مجموعة فرعيّة، ولا تزال تفترض تغيير الكود والاختبار.

6. اعثر على التقنيّات التي لا تنتقل بشكل نظيف

هذا أحد أهمّ أجزاء التمريرة قبل الترحيل. تحتفظ Microsoft بإرشادات حول التقنيّات التي كانت موجودة في .NET Framework لكنّها غير متوفّرة أو مختلفة بشكل كبير في .NET 6 وما بعدها.

6.1 التقنيّات الشائعة ذات العلم الأحمر

6.2 يتعلّق AppDomain بالنيّة، وليس فقط بالبحث عن الرموز

AppDomain صعب قليلاً لأنّ بعض مساحة API لا تزال موجودة على .NET الحديث، لكنّ إنشاء AppDomains جديدة للعزل غير مدعوم بالمعنى القديم.

لذا فإنّ السؤال الحقيقيّ للترحيل ليس فقط “هل تظهر كلمة AppDomain؟”
بل هو لماذا استُخدِمت AppDomain في المقام الأوّل؟

تشمل الأسباب النموذجيّة:

• عزل المكوّنات الإضافيّة
• إلغاء تحميل الكود المُحمَّل ديناميكيّاً
• عزل partial-trust
• صناديق تنفيذ قابلة للتخلّص

كلّ من هذه يحتاج إلى محادثة استبدال مختلفة.

6.3 يمكن أن يختبئ Remoting خلف أنماط قديمة

Remoting لا يتعلّق فقط بمراجع namespace الواضحة. أنماط السلوك القديمة مثل delegate BeginInvoke() / EndInvoke() يمكن أن تكون جزءاً من تدقيق الترحيل أيضاً.

تشمل مصطلحات البحث المفيدة:

• System.Runtime.Remoting
• MarshalByRefObject
• RealProxy
• BeginInvoke(
• EndInvoke(

6.4 غالباً ما يختبئ BinaryFormatter في أماكن أكثر ممّا هو متوقّع

يمكن للأنظمة القديمة أن تستخدم BinaryFormatter دون كثير من الوعي الظاهر. يحتاج التدقيق إلى التفكير في:

• الحالة المستمرّة
• الذاكرة المؤقّتة (caches)
• تخزين الجلسات
• حالة المكوّنات الإضافيّة
• عقود WCF أو SOAP القديمة
• ResX
• سلوك الحافظة والسحب والإفلات

في .NET 9 وما بعد، BinaryFormatter ليس مجرّد غير محبَّذ. تنفيذ runtime اختفى ومسار API يطلق PlatformNotSupportedException. ذلك يجعله قضيّة ما قبل الترحيل، وليس فكرة لاحقة.

6.5 مصطلحات بحث تستحقّ التشغيل قبل أيّ تقدير

حتّى البحث البسيط في الحلّ بأكمله عن المصطلحات التالية يمكن أن يغيّر صورة الترحيل بسرعة:

System.Web
HttpContext.Current
System.Runtime.Remoting
MarshalByRefObject
AppDomain
BinaryFormatter
ServiceHost
ChannelFactory
System.EnterpriseServices
Workflow
packages.config
web.config.install.xdt
install.ps1
DllImport
AxInterop
Microsoft.Office.Interop

العثور على أحد هذه المصطلحات ليس فشلاً تلقائيّاً.
إنّها خريطة لما يمكن للترحيل أن يتّبع فيه المسار العاديّ وما يصبح فيه مسار عمل مختلف.

7. قرّر مقدار السلوك المختصّ بـ Windows المقبول

أحد سوء الفهم الشائع جدّاً هو أنّ الانتقال إلى “.NET” يعني تلقائيّاً عبور الأنظمة الأساسيّة.
لا توجد مثل هذه السحريّة. إذا كان التطبيق مرتبطاً بعمق بـ Windows، فسيظلّ تطبيق Windows بعد الترحيل.

7.1 يمكن أن يكون البقاء على Windows فقط منطقة هبوط أولى صالحة

تقدّم Microsoft Windows Compatibility Pack، الذي يساعد .NET الحديث على استخدام كثير من APIs المتمحورة حول Windows مثل الوصول إلى registry و WMI و Event Log و Windows Service APIs و Directory Services.

هذا يهمّ كثيراً في الحالات التي يكون فيها الهدف الحقيقيّ على المدى القصير:

• الانتقال إلى .NET الحديث أوّلاً
• البقاء على Windows في الوقت الراهن
• قبول الاعتماد على Windows API كحالة مؤقّتة أو حتّى طويلة الأمد

يمكن أن يكون ذلك شكلاً معقولاً تماماً للترحيل.

7.2 لكنّ APIs المختصّة بـ Windows لا تزال ديناً مستقبليّاً

Windows Compatibility Pack مفيدة، لكنّها لا تمحو المقايضات.

إذا كانت الخطّة الأطول مدى تشمل أموراً مثل:

• Linux containers
• استضافة قائمة على Kubernetes
• builds مشتركة عبر مطوّري macOS و Linux و Windows
• تقليل بصمة Windows VM في السحابة

فإنّ الاعتماد على Windows API يحتاج إلى أن يصبح مرئيّاً في وقت مبكّر.

7.3 System.Drawing.Common مصدر متكرّر لسوء الفهم

منذ .NET 6، أصبحت System.Drawing.Common فعليّاً مقتصرة على Windows.

لذا إذا كان الكود يستخدمها لمعالجة الصور أو رسم النصوص، فإنّ أحد الأسئلة الأولى ينبغي أن يكون:

• هل سنبقى على Windows؟
• أم نريد في النهاية دعم Linux أو macOS؟

إذا كانت الإجابة هي Windows فقط في المستقبل المنظور، فقد يكون مقبولاً للوقت الحاليّ. إذا كانت الإجابة لا، فإنّ المكتبات البديلة مثل SkiaSharp أو ImageSharp تحتاج إلى الدخول في الخطّة في وقت مبكّر.

7.4 علامات شائعة على أنّ التطبيق مرتبط بـ Windows

عادةً ما تعني هذه المراجع أو APIs أنّ تقدير الترحيل الأوّل ينبغي أن يفترض منطقة هبوط مقتصرة على Windows:

• Microsoft.Win32.Registry
• System.Management
• System.Diagnostics.EventLog
• System.ServiceProcess
• System.DirectoryServices
• System.Drawing
• DllImport / P/Invoke
• مراجع COM
• AxInterop.*
• Microsoft.Office.Interop.*

8. غالباً ما تحدّد حدود المكتبات المشتركة الترحيل بأكمله

في الحلول الأكبر، تتشكّل صعوبة الترحيل بشكل كبير من خلال كيفيّة تقطيع المكتبات المشتركة.

8.1 ابدأ بثلاث فئات عريضة

من المفيد تصنيف المكتبات إلى ثلاثة أنواع:

1. منطق الأعمال أو المجال النقيّ
2. طبقات وسطى مع بعض الاعتماد على نموذج التطبيق
3. طبقات ملتصقة بإحكام بـ UI أو الويب أو Windows APIs

أفضل المرشّحين للنقل أوّلاً هم تقريباً دائماً الفئة الأولى.

• الحسابات
• القواعد
• DTOs والعقود
• خدمات المجال
• تحويلات البيانات المباشرة

عندما يتمّ استخراج هذا الجزء بنظافة، تنخفض الصعوبة بشكل حادّ في الغالب.

8.2 لا يزال .NET Standard 2.0 يعمل كجسر

لا تزال إرشادات Microsoft تجعل .NET Standard 2.0 الإجابة العمليّة عندما يجب استخدام مكتبة مشتركة من قِبَل جانب Framework القديم وجانب .NET الجديد على حدٍّ سواء.

تهمّ حقيقتان:

• .NET Framework لا يدعم .NET Standard 2.1
• إذا كانت المكتبة بحاجة إلى أن يُشار إليها من العالمَين، فإنّ 2.0 هو الجسر الواقعيّ في الغالب

8.3 ثلاث استراتيجيّات شائعة للمكتبات

8.4 وضع التوافق ليس حيلة سحريّة

يمكن أن يساعد وضع توافق .NET Standard 2.0 في بعض الحالات، لكنّه ليس إجابة شفّافة لكلّ شيء.
إذا كانت المكتبة تفترض WPF أو نموذج تطبيق محدّداً آخر، فإنّها لا تزال ليست مكتبة مشتركة فعلاً بالطريقة التي يحتاجها الترحيل.

8.5 مكتبات ASP.NET تعيش أو تموت بناءً على ما إذا كان من الممكن إزالة System.Web

بالنسبة لترحيل ASP.NET التدريجيّ، فإنّ المكتبات المشتركة التي تعتمد مباشرةً على HttpContext.Current أو System.Web تميل إلى أن تصبح مؤلمة بسرعة.

تشمل الاستراتيجيّات النموذجيّة:

• دفع تبعيّة System.Web خارج حدود العقد الرئيسيّة
• تمرير البيانات المشتقّة من الطلب كـ DTOs بدلاً من ذلك
• استخدام adapters أثناء الانتقال
• استخدام multi-targeting إذا لم يكن من الممكن إزالة التبعيّة فوراً

8.6 انقل المكتبات بشكل leaf-first

إرشادات ASP.NET التدريجيّة من Microsoft تصف نقل المكتبات الداعمة بترتيب postorder depth-first، أي فعليّاً leaf-first.

هذا قيّم أيضاً خارج مشاريع الويب:

• تستقرّ التبعيّات ذات المستوى الأدنى أوّلاً
• تبقى مشاكل التوافق محصورة لفترة أطول
• يصبح الاختبار على مستوى المكتبة أسهل

9. جرد حزم NuGet والتبعيّات المحلّيّة والمكوّنات الخارجيّة

هذا هو المكان الذي تعاني فيه كثير من عمليّات الترحيل في وقت متأخّر إذا كانت التمريرة المبكّرة سطحيّة جدّاً.

9.1 أربع سلاسل تبعيّات أكثر فائدة من قائمة حزم واحدة

من المفيد فصل التبعيّات إلى:

1. حزم NuGet العامّة
2. الحزم الداخليّة أو المكتبات الداخليّة
3. مراجع DLL محلّيّة
4. COM و ActiveX و DLL أصليّة وتكاملات ثنائيّة بأسلوب SDK

النظر فقط إلى حزم NuGet العامّة لا يكفي.
أخطر العناصر غالباً ما تكون الفئتان 3 و 4.

9.2 أسئلة تستحقّ السؤال لكلّ تبعيّة

لكلّ تبعيّة، اسأل على الأقلّ:

• هل تستهدف .NET الحديث؟
• هل تعمل مع PackageReference؟
• هل هي متوافقة مع مشاريع SDK-style؟
• هل توجد قيود x86 أو x64 أو ARM64؟
• هل تعتمد على أدوات وقت التصميم أو امتداد Visual Studio؟
• هل تفترض install scripts أو config transforms؟
• هل المنتج لا يزال مدعوماً؟

9.3 تحتاج مكوّنات UI الخارجيّة والتقارير ووقت التصميم إلى تقدير منفصل

هذا مهمّ بشكل خاصّ في أنظمة WinForms و WPF و ASP.NET.

• grids
• محرّكات التقارير
• مكتبات إخراج PDF
• مكوّنات الرسوم البيانيّة
• مكتبات UI مع تكامل المصمّم
• أغلفة ActiveX

تلك المكوّنات ليست فقط تبعيّات وقت تشغيل. غالباً ما تتضمّن سلوك وقت التصميم أيضاً، ممّا يعني أنّ “إنّه يجمَّع” لا يكفي كتقدير.

9.4 تحتاج DLL الأصليّة و bitness دائماً إلى مراجعة صريحة

كثير من الأنظمة القديمة بدت كأنّها تعمل كـ AnyCPU، لكنّها في الواقع كانت تعتمد على أمور مثل:

• COM مقتصر على x86 فقط
• عناصر تحكّم ActiveX 32-bit
• إصدار محدّد من VC++ runtime
• DLL أصليّة موقَّعة

.NET الحديث لا ينشئ تلك القيود. إنّه فقط يجعل القيود الموجودة منذ زمن طويل مرئيّة.

10. تعامل مع EF6 والسلسلة وأمور البيانات كمسار مشكلة منفصل

عادةً ما تسير حركة runtime وإعادة تصميم وصول البيانات أو السلسلة بشكل أفضل عندما لا تُجبَر على الدخول في المرحلة نفسها.

10.1 EF6 إلى EF Core ليس ترقية مباشرة

إرشادات EF من Microsoft صريحة: EF Core هي إعادة كتابة كاملة لـ EF6 ولا يوجد مسار ترقية مباشر.

عادةً ما يجعل ذلك التسلسل العمليّ:

1. الانتقال إلى .NET الحديث أوّلاً
2. الإبقاء على EF6 مؤقّتاً إذا قلّل ذلك من المخاطر
3. الترحيل إلى EF Core لاحقاً كمشروع منفصل

هذا الفصل يهمّ كثيراً.
مجرّد عدم دمج ترحيل runtime مع ترحيل ORM غالباً ما يخفّض ملفّ المخاطر بشكل كبير.

10.2 ما الذي يتغيّر إذا بقي EF6 لبعض الوقت

الفوائد:

• يمكن أن تتغيّر طبقة الوصول إلى البيانات لاحقاً
• يمكن للفريق التركيز على حركة runtime ونموذج التطبيق أوّلاً
• لا تختلط اختلافات السلوك من EF Core في المرحلة نفسها

التحذيرات:

• لا يزال EF Core هو الإعداد الافتراضيّ على المدى الطويل للتطوير الجديد
• يجلب استخدام EF6 Designer و EDMX قيوده الخاصّة

10.3 EF6 المستند إلى EDMX لديه قصّة وقت تصميم أيضاً

تشير وثائق EF6 أيضاً إلى أنّ EF Designer غير مدعوم مباشرةً في مشاريع .NET / .NET Standard أو في مشاريع .NET Framework SDK-style.

هذا يعني أنّ الأنظمة المستندة إلى EDMX تحتاج إلى ثلاثة أسئلة منفصلة:

• هل لا يزال تنفيذ runtime يعمل؟
• هل لا يزال سير عمل المصمّم يعمل؟
• كيف ستُعالَج الكود المُولَّد في المستقبل؟

إذا كان EDMX يُستخدَم بكثرة، فإنّ ذلك ينتمي إلى التقدير من اليوم الأوّل.

10.4 BinaryFormatter والسلسلة المخصّصة غالباً ما تكون تبعيّات خفيّة

من السهل التقليل من شأن السلسلة لأنّ بحث الكود البسيط قد لا يكشف عن التأثير الكامل.

فكّر في:

• تنسيقات البيانات المستمرّة
• أحمال الرسائل
• caches
• عقود WCF أو SOAP القديمة
• ResX
• سلوك الحافظة والسحب والإفلات

النقطة الرئيسيّة ليست فقط ما إذا كان الكود يجمَّع. إنّها ما إذا كانت البيانات الحاليّة لا تزال قابلة للقراءة ومتوافقة.

11. أدرج الإعدادات والنشر والتشغيل و CI/CD في حدود الترحيل

نطاق الترحيل ليس أبداً الكود المصدريّ فقط.

11.1 ملفّات الإعدادات

على جانب Framework، غالباً ما تحمل app.config و web.config أكثر بكثير ممّا تتذكّره الفِرَق:

• connection strings
• أقسام إعدادات مخصّصة
• إعدادات WCF endpoint
• binding redirects
• diagnostics
• إعدادات خاصّة بـ ASP.NET
• نتائج تحويلات تثبيت الحزم

يغيّر .NET الحديث شكل الإعدادات ومسارات التحميل في كثير من الحالات.
لذا فإنّ “سنصلح الإعدادات لاحقاً” عادةً فكرة محفوفة بالمخاطر.

الخطوة الأولى هي جرد الإعدادات:

• ما الذي يوجد بالضبط في ملفّات الإعدادات
• ما الذي يلزم عند بدء التشغيل
• ما الذي هو خاصّ بالبيئة
• ما الذي كان يُحقَن بواسطة NuGet أو المثبّتات

11.2 نموذج النشر

يهمّ أيضاً شكل النشر وبدء التشغيل:

• IIS؟
• Windows Service؟
• Scheduled Task؟
• ClickOnce أو MSI أو مثبّت مخصّص؟
• افتراضات خادم محلّيّ؟
• نشر self-contained أم framework-dependent؟

من الطبيعيّ جدّاً اكتشاف متأخّراً أنّ الكود يمكن أن يعمل لكنّ مسار النشر لا يزال مرتبطاً بنموذج تشغيل قديم.

11.3 التسجيل والمراقبة والممارسة التشغيليّة

من السهل تفويت افتراضات التشغيل:

• Windows Event Log
• Performance Counters
• المراقبة المستندة إلى WMI
• افتراضات حساب الخدمة والصلاحيّات الثابتة
• افتراضات تسجيل الملفّات المحلّيّة

تطبيق مرحَّل يعمل لكن لا يتناسب مع نموذج التشغيل لا يزال غير مرحَّل حقّاً.

11.4 CI/CD و build agents

قبل الترحيل، راجع على الأقلّ:

• ما إذا كان بإمكان build agents استضافة .NET SDKs المطلوبة
• ما الذي ينبغي عمله بـ pipelines المتمحورة حول nuget.exe و msbuild.exe
• ما إذا كان ينبغي للـ pipeline الانتقال نحو dotnet CLI
• كيف ينبغي تغيير تنفيذ الاختبارات والتغطية ومهامّ النشر
• ما إذا كانت قوالب pipeline الداخليّة لا تزال تفترض اتّفاقيّات مشاريع قديمة

“يعمل محلّيّاً لكنّ CI ميّت” هي إحدى أكثر نتائج الترحيل عاديّةً عندما يُتجاهَل ذلك.

12. تسلسل ترحيل واقعيّ

بمجرّد أن يصبح ما سبق واضحاً، يستقرّ مسار الترحيل غالباً في شيء كالتالي.

12.1 حدِّث جانب Framework الحاليّ أوّلاً

1. الانتقال إلى .NET Framework 4.7.2 أو أحدث، ومن الناحية المثاليّة 4.8.1
2. تحديث التبعيّات
3. فحص وتقليل packages.config
4. الاتّجاه نحو PackageReference ومشاريع SDK-style حيث يكون ذلك ممكناً
5. التأكّد من أنّ التطبيق الحاليّ لا يزال يجمَّع ويبدأ ويجتاز الاختبارات في تلك الحالة

هذا وحده يزيل في الغالب كميّة كبيرة من الضوضاء اللاحقة.

12.2 أنقذ المكتبات المشتركة بعد ذلك

انقل منطق الأعمال والعقود المشتركة نحو netstandard2.0 أو multi-targeting.
استخدم ترتيب leaf-first كإعداد افتراضيّ.

12.3 غيّر الاستراتيجيّة حسب نموذج التطبيق

• مكتبات الفئات وأدوات وحدة التحكّم وبعض الخدمات
  غالباً ما يكون المسار الأكثر مباشرة
• WinForms / WPF
  حدِّث مع البقاء عمداً على Windows فقط
• ASP.NET MVC / Web API
  دفعةً واحدة للأنظمة الصغيرة، ترحيل تدريجيّ للأكبر
• Web Forms
  افترض استبدال UI وانقل المنطق المشترك أوّلاً
• WCF server
  اختر مبكّراً بين التوافق عبر CoreWCF وإعادة التصميم عبر gRPC أو HTTP APIs

12.4 لا تفعل كلّ شيء في sprint واحد

تشمل التركيبات التي يجب تجنّبها:

• ترحيل runtime مع استبدال ORM كامل
• ترحيل runtime مع استبدال منصّة المصادقة
• ترحيل runtime مع نقل سحابيّ كامل
• ترحيل runtime مع استبدال منصّة المراقبة
• ترحيل runtime مع استبدال إطار عمل UI

حتّى لو كانت كلّ هذه التغييرات ضروريّة في النهاية، فإنّها عادةً ما تكون أفضل كمراحل منفصلة.

12.5 احصل على اختبارات وخطوط أساس قبل الحركة الخطرة

كحدّ أدنى، من المفيد أن يكون لديك:

• اختبارات وحدة
• اختبارات تكامل لتدفّقات الأعمال الرئيسيّة
• فحوصات بأسلوب snapshot للشاشات أو APIs التمثيليّة
• خطوط أساس للأداء
• طريقة معروفة لفحص السجلّات الرئيسيّة
• إجراءات تراجع

المضيّ قدماً دون طريقة لتحديد ما الذي تعطّل بعد الترحيل هو أمر عالي المخاطر.

13. قائمة تحقّق ما قبل الترحيل

هذا القسم مصمّم ليكون قابلاً لإعادة الاستخدام مباشرةً في تخطيط المشاريع.

13.1 الاتّجاه

• يمكننا أن نشرح في جملة واحدة لماذا نقوم بالترحيل
• قرّرنا ما إذا كانت منطقة الهبوط هي .NET الحديث المقتصر على Windows أو عبور الأنظمة الأساسيّة المستقبليّ
• اخترنا إصدار .NET المستهدف
• أدرجنا صراحةً ما هو خارج النطاق لهذه المرحلة، مثل ترحيل EF Core أو إعادة تصميم المصادقة أو الانتقال السحابيّ الكامل

13.2 تنظيف .NET Framework الحاليّ

• نقلنا جانب Framework إلى 4.7.2 أو أحدث، ومن الناحية المثاليّة 4.8.1
• حدّثنا التبعيّات نحو الإصدارات المدعومة الحاليّة
• تحقّقنا من المواقع التي لا يزال packages.config موجوداً فيها
• قيّمنا جدوى تحويل PackageReference
• قيّمنا جدوى تحويل SDK-style
• التطبيق الحاليّ لا يزال يجمَّع ويبدأ ويجتاز الاختبارات في تلك الحالة المنظَّفة

13.3 خيارات نموذج التطبيق والتقنيّة

• قدّرنا الصعوبة بشكل منفصل حسب مكتبة الفئات وسطح المكتب والويب و WCF وأنواع المشاريع المماثلة
• نفهم أنّ WinForms و WPF يبقيان مقتصرَين على Windows
• نفهم أنّ ترحيل ASP.NET Framework إلى ASP.NET Core هو ترحيل لنموذج التطبيق
• أدرجنا استبدال UI لـ Web Forms في التقدير
• قيّمنا WCF clients بشكل منفصل عن WCF servers

13.4 التقنيّات غير المدعومة أو عالية المخاطر

• دقّقنا في الاعتماد على AppDomain
• دقّقنا في Remoting و MarshalByRefObject و BeginInvoke و EndInvoke
• دقّقنا في CAS و Security Transparency و COM+ و Workflow Foundation
• دقّقنا في الاعتماد على BinaryFormatter
• دقّقنا في الاعتماد على System.Web

13.5 الاعتماد على Windows فقط

• دقّقنا في استخدام registry و WMI و Event Log و Windows Service و Directory Services
• دقّقنا في استخدام System.Drawing.Common
• دقّقنا في استخدام COM و ActiveX و Office Interop و P/Invoke و DLL أصليّة
• فحصنا قيود x86 و x64 و ARM64

13.6 المكتبات المشتركة والوصول إلى البيانات

• صنّفنا المكتبات المشتركة إلى منطق أعمال مقابل طبقات معتمدة على نموذج التطبيق
• حدّدنا المكتبات التي يمكن أن تنتقل إلى netstandard2.0
• حدّدنا المكتبات التي تحتاج إلى multi-targeting
• قرّرنا ما إذا كان بإمكان EF6 البقاء بينما ينتقل runtime فقط أوّلاً
• فحصنا الاعتماد على EDMX والمصمّم

13.7 التشغيل و build

• جردنا ملفّات الإعدادات
• راجعنا شكل النشر مثل IIS و Service و MSI و ClickOnce
• راجعنا افتراضات التسجيل والمراقبة والصلاحيّات وحساب التنفيذ
• راجعنا ما إذا كانت CI/CD و build agents تحتاج إلى تحديثات
• أعددنا إجراءات التراجع

14. الخلاصة

الجزء المهمّ من ترحيل .NET Framework إلى .NET ليس فقط تسلسل الأوامر.
إنّه تحديد، قبل بدء التنفيذ، ما يمكن نقله مباشرةً وما هو في الواقع مشكلة مختلفة.

اللبّ العمليّ هو:

• نظّف جانب Framework أوّلاً
• قدّر حسب نموذج التطبيق، وليس حسب حجم الكود العامّ
• اعثر على التقنيّات غير المدعومة في وقت مبكّر
• قرّر مقدار السلوك المختصّ بـ Windows المقبول
• قرّر كيف ستُعالَج حدود المكتبات المشتركة
• تجنّب حزم ORM والمصادقة والسحابة وعمليّات إعادة التصميم الكبيرة الأخرى في الحركة نفسها

غالباً ما تتغيّر دقّة تقدير الترحيل بشكل كبير في الأسبوع الأوّل.
إذا استُخدِم ذلك الأسبوع الأوّل لإظهار الافتراضات بوضوح، فإنّ بقيّة المشروع يبدأ في أن يبدو أكثر بكثير مثل عمل هندسيّ عاديّ.

“دعنا فقط نغيّر الهدف إلى net10.0 ونرى ما يحدث” ليست تجربة عديمة الفائدة.
لكن كاستراتيجيّة ترحيل إنتاجيّة، فإنّها تبدأ متأخّرة جدّاً. العمل الحقيقيّ يبدأ قبل ذلك.

15. المراجع

• Prerequisites for porting code to .NET
• Overview of porting from .NET Framework to .NET
• Technologies unavailable on .NET
• GitHub Copilot app modernization overview
• GitHub Copilot app modernization installation
• .NET support policy
• .NET Framework support policy
• Migrate ASP.NET Framework to ASP.NET Core with tooling
• Migrate from ASP.NET Framework to ASP.NET Core
• Get started with incremental ASP.NET to ASP.NET Core migration
• Use the Windows Compatibility Pack to port code to .NET
• .NET Standard
• Cross-platform targeting for .NET libraries
• Migrate from packages.config to PackageReference
• PackageReference in project files
• BinaryFormatter migration guide
• BinaryFormatter migration guidance for Windows Forms
• WCF Client support policy
• CoreWCF support policy
• Why migrate WCF to ASP.NET Core gRPC
• Port from EF6 to EF Core
• What’s new in EF6

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.