تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.
ترحيل تطبيق .NET Framework قديم إلى .NET الحديث هو أحد تلك المهام التي يعلم الجميع أنه يجب القيام بها لكن لا أحد يريد البدء بها. إنها ليست مجرد “تغيير إطار العمل الهدف.” إنها واجهات API اختفت، وحزم لم تعد موجودة، ونماذج استضافة تعمل بشكل مختلف تمامًا، وملايين القرارات الصغيرة حول ما تضعه في حاوية، وما تُعيد كتابته، وما تتركه كما هو.
نشر Jeffrey Fritz للتو تعمقًا كاملًا في تقييم تحديث GitHub Copilot، وصراحةً؟ هذه أفضل أدوات الترحيل التي رأيتها لـ .NET. ليس بسبب توليد الكود — هذا أصبح أمرًا مفروغًا منه الآن. بل بسبب وثيقة التقييم التي تُنتجها.
إنها ليست مجرد محرك اقتراحات كود
تتبع إضافة VS Code نموذج تقييم ← تخطيط ← تنفيذ. تُحلّل مرحلة التقييم قاعدة الكود بأكملها وتُنتج وثيقة منظمة تلتقط كل شيء: ما يحتاج إلى التغيير، وموارد Azure المراد توفيرها، ونموذج النشر المراد استخدامه. كل ما يلي — كود البنية التحتية، والحاويات، وبيانات النشر — ينبع مما يجده التقييم.
يُخزَّن التقييم تحت .github/modernize/assessment/ في مشروعك. كل تشغيل يُنتج تقريرًا مستقلًا، لذا تبني سجلًا تاريخيًا ويمكنك تتبع كيف تتطور وضعية الترحيل لديك كلما أصلحت المشكلات.
طريقتان للبدء
التقييم الموصى به — المسار السريع. اختر من بين المجالات المنسّقة (ترقية Java/.NET، جاهزية السحابة، الأمان) واحصل على نتائج ذات معنى دون لمس التكوين. رائع للنظرة الأولى على وضع تطبيقك.
التقييم المخصص — المسار المستهدف. قم بتكوين ما تريد تحليله بالضبط: الحوسبة المستهدفة (App Service، AKS، Container Apps)، نظام التشغيل المستهدف، تحليل الحاويات. اختر أهدافًا متعددة على Azure لمقارنة مناهج الترحيل جنبًا إلى جنب.
عرض المقارنة مفيد حقًا. تطبيق به 3 مشكلات إلزامية لـ App Service قد يكون لديه 7 لـ AKS. رؤية كليهما يساعد في اتخاذ قرار الاستضافة قبل الالتزام بمسار الترحيل.
تفصيل المشكلات قابل للتنفيذ
كل مشكلة تأتي بمستوى حرجية:
- إلزامية — يجب إصلاحها وإلا يفشل الترحيل
- محتملة — قد تؤثر على الترحيل، تحتاج إلى حكم بشري
- اختيارية — تحسينات موصى بها، لن تعيق الترحيل
وكل مشكلة تربط بالملفات والأسطر المتأثرة، وتُقدم وصفًا تفصيليًا لما هو خاطئ ولماذا يهم ذلك للمنصة المستهدفة، وتُعطي خطوات معالجة ملموسة (ليس فقط “أصلح هذا”)، وتتضمن روابط للتوثيق الرسمي.
يمكنك تسليم مشكلات فردية للمطورين وسيكون لديهم كل ما يحتاجون إليه للتصرف. هذا هو الفرق بين أداة تخبرك “هناك مشكلة” وأخرى تخبرك كيف تحلها.
مسارات الترقية المدعومة
لـ .NET تحديدًا:
- .NET Framework ← .NET 10
- ASP.NET ← ASP.NET Core
كل مسار ترقية له قواعد كشف تعرف أي واجهات API أُزيلت، وأي أنماط ليس لها مقابل مباشر، وما هي مشكلات الأمان التي تحتاج إلى اهتمام.
بالنسبة للفرق التي تدير تطبيقات متعددة، هناك أيضًا واجهة سطر أوامر (CLI) تدعم تقييمات دفعية متعددة المستودعات — استنسخ جميع المستودعات، وقيّمها جميعًا، واحصل على تقارير لكل تطبيق بالإضافة إلى عرض تجميعي للمحفظة.
رأيي
إذا كنت تجلس على تطبيقات .NET Framework قديمة (ولنكن صريحين، معظم فرق المؤسسات كذلك)، فهذه هي الأداة التي تبدأ بها. وثيقة التقييم وحدها تستحق الوقت — إنها تحوّل “يجب أن نحدّث” الغامضة إلى قائمة ملموسة ذات أولويات من بنود العمل مع مسارات واضحة للمضي قدمًا.
سير العمل التعاوني ذكي أيضًا: صدّر التقييمات، وشاركها مع فريقك، واستوردها دون إعادة التشغيل. مراجعات المعمارية حيث صانعو القرار ليسوا من يشغّل الأدوات؟ مغطاة.
خلاصة
يحوّل تقييم تحديث GitHub Copilot ترحيل .NET من مشروع مخيف وغير محدد إلى عملية منظمة وقابلة للتتبع. ابدأ بتقييم موصى به لترى وضعك، ثم استخدم التقييمات المخصصة لمقارنة أهداف Azure وبناء خطة الترحيل.
اقرأ الشرح التفصيلي الكامل واحصل على إضافة VS Code لتجربتها على قاعدة الكود الخاصة بك.
