قدم بواسطة. NET 5

في 6 مايو ، تم الإعلان عن أن الإصدار التالي بعد .NET Core 3.0 سيكون .NET 5. سيكون هذا هو الإصدار الكبير التالي في عائلة .NET.

في المستقبل ، سيكون هناك .NET واحدة فقط ، ويمكنك استخدامه للتطوير في أنظمة Windows و Linux و macOS و iOS و Android و tvOS و watchOS و WebAssembly وغيرها من المنصات.

سنقدم واجهات برمجة التطبيقات .NET الجديدة ، وإمكانات وقت التشغيل ، وميزات اللغة كجزء من .NET 5.



منذ إطلاق مشروع .NET Core ، أضفنا حوالي 50 ألف واجهة برمجة تطبيقات .NET Framework إلى النظام الأساسي. قدر الإمكان ، اقترب .NET Core 3.0 من .NET Framework 4.8 ، وبفضل ذلك أصبح Windows Forms و WPF و Entity Framework 6. متاحًا ، وتولّى .NET 5. تطبيق الويب ، واستند إلى .NET Core وكل ما هو أفضل من مشروع Mono ، مما أدى إلى اتضح أنه نظام أساسي واحد يمكن استخدامه لجميع رموز .NET الحديثة.

نعتزم إصدار .NET 5 في نوفمبر 2020 ، وسيكون إصدار المعاينة الأول متاحًا في النصف الأول من عام 2020. سيكون النظام الأساسي متاحًا جنبًا إلى جنب مع التحديثات المستقبلية لـ Visual Studio 2019 و Visual Studio for Mac و Visual Studio Code.

.NET 5 = .NET Core vNext

.NET 5 هي الخطوة التالية في .NET Core. يهدف المشروع إلى تحسين .NET في العديد من الجوانب الرئيسية:

• قم بإنشاء وقت تشغيل وإطار عمل فرديين يمكن استخدامهما في كل مكان ، بنفس تجربة تطوير السلوك والسلوك.
• قم بتوسيع .NET مع أفضل من .NET Core و .NET Framework و Xamarin و Mono.
• أنشئ منتجًا من قاعدة شفرة واحدة يمكن للمطورين (من Microsoft والمجتمع) العمل معها وتوسيعها ، مما سيحسن جميع السيناريوهات الممكنة.

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

تم الحفاظ على كل ما يعجبك في .NET Core:

• المصدر المفتوح والتركيز على المجتمع جيثب.
• تنفيذ عبر منصة.
• دعم لاستخدام ميزات معينة خاصة بالنظام الأساسي ، مثل Windows Forms و WPF for Windows ، وكذلك الارتباطات الأصلية لكل نظام أساسي أصلي من Xamarin.
• عالية الأداء.
• جنبا إلى جنب التثبيت.
• حجم ملف المشروع الصغير (نمط SDK).
• واجهة سطر أوامر قوية (CLI).
• التكامل مع Visual Studio و Visual Studio for Mac و Visual Studio Code.

ابتكارات:

• سيكون لديك المزيد من إمكانات وقت التشغيل (المزيد حول هذا أدناه).
• ستتوفر إمكانية الاتصال برمز Java من .NET 5 على جميع الأنظمة الأساسية.
• سيتم دعم استدعاء رمز الهدف والهدف من .NET 5 على عدة أنظمة تشغيل.
• سيتم توسيع CoreFX لدعم تجميع NET (AOT) الثابت (AOT) ، لتقليل آثار الأقدام ودعم المزيد من أنظمة التشغيل.

سيتوفر .NET Core 3.0 في سبتمبر من هذا العام ، وسيكون .NET 5 متاحًا في نوفمبر 2020. بعد ذلك ، سنصدر إصدارات رئيسية من .NET مرة واحدة في العام ، كل نوفمبر:



لقد تخطينا الإصدار الرابع ، لأن المستخدمين قد يتعرضون للارتباك مع .NET Framework ، الذي تم إصداره منذ فترة طويلة في الإصدار 4.x. بالإضافة إلى ذلك ، أردنا توضيح أن .NET 5 هو مستقبل النظام الأساسي .NET.

قررنا أيضًا اغتنام هذه الفرصة وتبسيط ترتيب الأسماء. نعتقد أنه إذا تم تطوير .NET واحدة فقط ، فلن نحتاج إلى المصطلح التوضيحي "Core". الاسم المختصر أبسط ، فهذا يعني أن ميزات وسلوك .NET 5 موحدة. إذا أردت ، يمكنك متابعة استخدام الاسم. NET Core.

بيئات وقت التشغيل

Mono هو تطبيق cross-platform الأصلي لـ .NET. لقد بدأ كبديل مفتوح المصدر لـ .NET Framework ، وبعد ذلك ، مع تزايد شعبية أجهزة iOS و Android ، قمنا بإعادة توجيهه إلى قطاع الأجهزة المحمولة. Mono هي بيئة وقت تشغيل تُستخدم كجزء من Xamarin.

CoreCLR هي بيئة وقت تشغيل تُستخدم كجزء من .NET Core. يركز في البداية على دعم التطبيقات السحابية ، بما في ذلك أكبر الخدمات في Microsoft ، ويستخدم اليوم أيضًا لتطبيقات سطح مكتب Windows ، إنترنت الأشياء ، والتعلم الآلي.

هناك الكثير من العوامل المشتركة بين عمليتي .NET Core و Mono (مع ذلك ، كلاهما عمليتان. NET) ، لكن لكل منهما قدراته الفريدة الخاصة به. لذلك ، فمن المنطقي أن نمنحك الفرصة لاختيار تجربة الاستخدام التي تحتاج إليها. نعمل حاليًا على استبدال بدائل المكونات الأساسية لـ CoreCLR و Mono لبعضها البعض. ستكون العملية بسيطة مثل تبديل التجميع للاختيار بين خيارات وقت التشغيل المختلفة.

في الفصول التالية ، سوف أصف خططنا الرئيسية لبرنامج .NET 5. وسوف يساعدونك في فهم كيفية تطوير عمليتين في نفس الوقت وفي نفس الوقت بشكل منفصل.

إنتاجية عالية وإنتاجية

منذ البداية ، اعتمد .NET على برنامج التحويل البرمجي JIT لتحويل رمز اللغة الوسيطة إلى رمز الجهاز الأمثل. لقد أنشأنا أفضل بيئة وقت تشغيل في الصناعة مع JIT ، مع أداء عالٍ للغاية ، مع السماح للمطورين بكتابة التعليمات البرمجية بسرعة وسهولة.

تعتبر برامج التحويل البرمجي JIT مناسبة تمامًا للسحب والنصوص العميلة على المدى الطويل. يمكنهم إنشاء رمز يأخذ في الاعتبار ميزات تكوين الأجهزة ، بما في ذلك تعليمات المعالج المحددة. يمكن لـ JIT أيضًا إنشاء طرق في وقت التشغيل مرة أخرى ، حيث تتيح لك هذه التقنية إمكانية التجميع بسرعة عالية ، وفي الوقت نفسه تقوم بإنشاء إصدار مضبوط بدقة من التعليمات البرمجية في حالة استخدام بعض الأساليب بشكل متكرر.

تعد جهودنا لتسريع أداء ASP.NET Core ، والتي انعكست في نتائج معايير TechEmpower ، مثالًا جيدًا على إمكانيات JIT وهي مساهمتنا في CoreCLR. حاولنا إعداد .NET Core لاستخدام الحاويات ، وهذا يوضح قدرة بيئة وقت التشغيل على التكيف ديناميكيًا مع البيئات المحدودة.

أدوات المطور هي مجال آخر أثبتت فيه JIT نفسها ، على سبيل المثال ، مشاهدة dotnet أو وضع "التحرير والمتابعة". غالبًا ما تتطلب الأدوات تجميع التعليمات البرمجية وتنزيلها في نفس العملية عدة مرات دون إعادة التشغيل ، وتحتاج إلى القيام بذلك بسرعة كبيرة.

يعتمد المطورين الذين يستخدمون .NET Core أو .NET Framework بشكل أساسي على JIT. لذلك يجب أن يبدو مألوفا لهم.

تتمثل الطريقة القياسية لمعظم أحمال عمل .NET 5 في استخدام وقت تشغيل CoreCLR مع JIT. هناك استثناءان مهمان هما iOS والعميل Blazor (WebAssembly) ، وهما يتطلبان تجميعًا أوليًا (متقدمًا).

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

كجزء من مشروع Mono ، كانت معظم الجهود موجهة إلى قطاع الأجهزة المحمولة وأجهزة الألعاب. الفرصة والنتيجة الرئيسية لهذا المشروع هي برنامج التحويل البرمجي AOT لـ .NET ، الذي تم تطويره استنادًا إلى برنامج التحويل البرمجي LLVM . يسمح لك برنامج التحويل البرمجي Mono AOT بترجمة التعليمات البرمجية .NET إلى رمز تنفيذي واحد يمكن تشغيله على أي جهاز ، تمامًا مثل رمز C ++. يمكن تنفيذ تطبيقات ما قبل التحويل البرمجي (AOT) بكفاءة باستخدام موارد محدودة (أماكن صغيرة) ، وإذا لزم الأمر ، التضحية بالأداء من أجل إطلاقها.

يستخدم مشروع Blazor بالفعل Mono AOT وهو واحد من أول من ينتقل إلى .NET 5. نستخدمه كأحد الطرق لإثبات خططنا.

هناك نوعان من حلول AOT:

• تتطلب تجميع AOT الكامل.
• الحلول ، التي يتم تجميع معظم رموزها باستخدام AOT ، ولكن لا يزال يسمح لك باستخدام JIT أو مترجم فوري لأنماط الأكواد هذه غير الأصدقاء مع AOT (على سبيل المثال ، الأدوية العامة).

أحادي AOT يدعم كلا النوعين. هناك حاجة إلى AOT من النوع الأول لنظام التشغيل iOS وبعض وحدات التحكم في الألعاب ، ويرجع ذلك أساسًا إلى متطلبات الأمان. حلول النوع الثاني أكثر تفضيلًا لأنها تمتلك جميع مزايا AOT دون عيوبها.

.NET Native هو برنامج التحويل البرمجي AOT الذي نستخدمه لتطبيقات Windows UWP. إنه ينتمي إلى النوع الأول من حلول AOT. في هذا التطبيق بالتحديد ، قمنا بتقييد واجهة برمجة تطبيقات .NET والخيارات المتاحة لك. ساعدنا ذلك في فهم أن حلول AOT يجب أن تغطي المجموعة الكاملة من واجهات برمجة التطبيقات وأنماط .NET.

سيظل تجميع AOT ضروريًا لنظام التشغيل iOS و WebAssembly وبعض وحدات التحكم في الألعاب. سنجعلها اختيارية للتطبيقات المضمنة في الأجهزة (مثل الأجهزة) ، والتي تتطلب بداية سريعة و / أو انخفاض استهلاك وحدة المعالجة المركزية.

الأساسيات والمتطلبات ذات الصلة

من الأهمية بمكان بالنسبة لنا أن نستمر في التطور كمنصة مع عناصر تحكم للإطلاق والأداء واستهلاك الذاكرة والموثوقية والتشخيصات. في الوقت نفسه ، من المستحسن تركيز جهودنا. سنعمل أكثر لتحسين الأداء والموثوقية في CoreCLR ، وكذلك لتحسين التشغيل وخفض حجم ملف برنامج التحويل البرمجي Mono AOT. يبدو لنا مزيج جيد. يسير الأداء والموثوقية جنبًا إلى جنب مع سرعة بدء التشغيل مع انخفاض أحجام الملفات.

من المستحسن استثمار موارد مختلفة في تحسين بعض الخصائص ، ولكن ليس في تحسين الآخرين.

يجب أن تكون قدرات التشخيص هي نفسها خلال .NET 5 ، وهذا ينطبق على كل من الوظيفة والأداء. من المهم أيضًا دعم نفس المعالجات ونظام التشغيل (باستثناء iOS و WebAssembly).

سنستمر في تحسين .NET 5 لجميع أنواع أعباء العمل والبرامج النصية مما يجعل هذا الأمر منطقيًا. سيتم التركيز بشكل كبير على التحسينات ، خاصة في الحالات التي تفرض فيها الأحمال المختلفة متطلبات مماثلة.

ستستخدم جميع تطبيقات .NET 5 إطار عمل CoreFX . سوف نتأكد من أن CoreFX يعمل بشكل جيد حيث لا يتم استخدامه اليوم ، وخاصة مهام Xamarin Blazor client.

يمكن بناء جميع تطبيقات .NET 5 باستخدام .NET CLI ، بحيث يكون في مجموعة المشاريع مجموعة أدوات واحدة تستند إلى سطر الأوامر.

سيتطور C # مع .NET 5. سيتاح للمطورين الذين يكتبون تطبيقات .NET 5 الوصول إلى أحدث إصدار من C # وخصائصه.

ولادة المشروع

كفريق فني ، اجتمعنا في ديسمبر 2018 في بوسطن لبدء هذا المشروع. تحدث كبار المهندسين المعماريين من فريق .NET (Mono / Xamarin و .NET Core) و Unity عن مختلف القدرات التقنية واتجاه تطوير البنية.

الآن نحن ننقل المشروع كفريق واحد. منذ ديسمبر ، حققنا تقدما كبيرا في العديد من المشاريع:

• حددنا المستوى الأدنى الذي يحدد تفاعل وقت التشغيل وطبقة الشفرة المدارة من أجل جعل> 99٪ CoreFX رمزًا شائعًا.
• يمكن MonoVM الآن استخدام CoreFX ومكتبات الفئة الخاصة به.
• أجرينا جميع اختبارات CoreFX على MonoVM باستخدام تنفيذها.
• أطلقت تطبيقات ASP.NET Core 3.0 على MonoVM.
• أطلقت MonoDevelop و Visual Studio لنظام التشغيل Mac على CoreCLR.

تثير متابعة تطبيق .NET واحد أسئلة مهمة. ماذا سيكون الإطار النهائي؟ هل ستظل قواعد توافق حزمة NuGet؟ ما هو الحمل الذي سيدعمه .NET 5 SDK خارج الصندوق؟ كيفية كتابة التعليمات البرمجية لبنية محددة؟ هل نحن بحاجة إلى .NET Standard؟ نعمل الآن على كل هذا وسنكون قادرين على مشاركة وثائق المشروع معك حتى تتمكن من قراءتها وإبداء الرأي.

استنتاج

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

لدينا مستقبل مشرق ، حيث يمكنك استخدام نفس واجهات برمجة التطبيقات .NET واللغات لمجموعة واسعة من التطبيقات وأنظمة التشغيل وبنية المعالج. يمكنك بسهولة تغيير تكوين البنية من خلال تجميع التطبيقات كما تريد - في Visual Studio أو Visual Studio for Mac أو Visual Studio Code أو Azure DevOps أو من سطر الأوامر.