الإعلان عن .NET Core 3.0 Preview 6

اليوم ، نعلن عن .NET Core 3.0 Preview 6 . ويتضمن تحديثات لتجميع التجميعات لتحسين بدء التشغيل ، وتحسين التطبيقات للحجم مع تحسينات رابط و EventPipe. لقد أصدرنا أيضًا صور Docker جديدة لـ Alpine على ARM64.

• قم بتنزيل .NET Core 3.0 Preview 6 الآن على Windows و macOS و Linux.

• تم نشر ملاحظات الإصدار في dotnet / core . يتوفر فرق API بين المعاينة 5 و 6 أيضًا.

• ASP.NET Core و EF Core يصدران أيضًا تحديثات اليوم.

• إذا فاتتك ذلك ، تحقق من التحسينات التي أصدرناها في .NET Core 3.0 Preview 5 ، منذ الشهر الماضي.

تحديث WPF و Windows Forms

أكمل فريق WPF الآن نشر معظم قاعدة بيانات WPF إلى GitHub . في الواقع ، لقد نشروا للتو مصدرًا لخمسة عشر جمعية . لأي شخص مطلع على WPF ، يجب أن تكون أسماء التجميع مألوفة جدًا.

في بعض الحالات ، لا تزال الاختبارات متراكمة لنشرها في أو قبل 3.0 GA. ومع ذلك ، فإن وجود كل هذا الكود يجب أن يمكّن مجتمع WPF من المشاركة الكاملة في إجراء التغييرات عبر WPF. من الواضح من قراءة بعض مشكلات GitHub أن المجتمع لديه تراكمه الخاص الذي ينتظر انتظار تحقيقه. موضوع الظلام ، ربما؟

صور عامل ميناء جبال الألب

صور Docker متاحة الآن لكل من .NET Core و ASP.NET Core على ARM64. كانت في السابق متاحة فقط ل x64.

يمكن استخدام الصور التالية في Dockerfile ، أو docker pull ، كما هو موضح أدناه:

• docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8
• docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8

تحسينات أنابيب الحدث

يدعم "توجيه الإخراج" الآن جلسات متعددة. هذا يعني أنه يمكنك استهلاك الأحداث مع EventListener في proc وفي الوقت نفسه لديك عملاء توجيه الإخراج خارج العملية.

تمت إضافة عدادات Perf جديد:

• ٪ الوقت في GC
• الجنرال 0 كومة الحجم
• الجنرال 1 كومة الحجم
• الجنرال 2 كومة الحجم
• حجم كومة LOH
• معدل التخصيص
• عدد التجميعات المحملة
• عدد المواضيع ThreadPool
• رصد معدل الخلاف قفل
• قائمة انتظار عناصر العمل
• ThreadPool معدل العمل المنجز

تطبيق Profiler attach يتم تطبيقه الآن باستخدام نفس بنية Event Pipe.

راجع اللعب باستخدام عدادات من David Fowler للحصول على فكرة عما يمكنك القيام به باستخدام توجيه الأحداث لإجراء تحقيقات الأداء الخاصة بك أو فقط مراقبة حالة التطبيق.

راجع عدادات dotnet لتثبيت أداة عدادات dotnet.

حسّن تطبيقاتك. NET الأساسية مع صور ReadyToRun

يمكنك تحسين وقت بدء تشغيل تطبيق .NET Core الخاص بك عن طريق تجميع تجميعات التطبيق كتنسيق ReadyToRun (R2R). R2R هو شكل من أشكال التجميع المسبق (AOT).

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

R2R معتمد مع .NET Core 3.0. لا يمكن استخدامه مع الإصدارات السابقة من .NET Core.

عينة أرقام الأداء

فيما يلي أرقام الأداء التي تم جمعها باستخدام تطبيق نموذج WPF . تم نشر التطبيق على أنه قائم بذاته ولم يستخدم رابط التجميع (تم تغطيته لاحقًا بهذا المنشور).

تطبيق IL- فقط:

• وقت بدء التشغيل: 1.9 ثانية
• استخدام الذاكرة: 69.1 ميغابايت
• حجم التطبيق: 150 ميغابايت

مع صور ReadyToRun:

• وقت بدء التشغيل: 1.3 ثانية.
• استخدام الذاكرة: 55.7 ميغابايت
• حجم التطبيق: 156 ميغابايت

صور جاهزة ، شرح

يمكنك R2R ترجمة كل من المكتبات وثنائيات التطبيق. في الوقت الحالي ، يمكن فقط تجميع مكتبات R2R كجزء من التطبيق ، وليس للتسليم كحزمة NuGet. نود الحصول على مزيد من التعليقات حول مدى أهمية هذا السيناريو.

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

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

من حيث التوافق ، تشبه صور ReadyToRun تجميعات IL ، مع بعض الاختلافات الرئيسية.

• التجميعات IL تحتوي على رمز IL فقط. يمكن تشغيلها في أي وقت تشغيل يدعم إطار العمل المحدد لهذا التجميع. على سبيل المثال ، يمكن تشغيل تجميع netstandard2.0 على .NET Framework 4.6+ و .NET Core 2.0+ ، على أي نظام تشغيل مدعوم (Windows ، macOS ، Linux) والهندسة المعمارية (Intel ، ARM ، 32 بت ، 64 بت).
• تحتوي التجميعات R2R IL و رمز الأصلي. يتم تصنيفها للحصول على الحد الأدنى لإصدار وقت تشغيل .NET Core المحدد وبيئة التشغيل (RID). على سبيل المثال ، قد يتم تجميع تجميع netstandard2.0 R2R لـ .NET Core 3.0 و Linux x64. سيكون قابلاً للاستخدام فقط في ذلك أو في تكوين متوافق (مثل .NET Core 3.1 أو .NET Core 5.0 ، على Linux x64) ، لأنه يحتوي على تعليمة برمجية أصلية يمكن استخدامها فقط في بيئة التشغيل هذه.

تعليمات

يعد تجميع ReadyToRun ميزةً قابلة للنشر فقط. لقد أصدرنا نسخة معاينة منه مع .NET Core 3.0 Preview 5.

لتمكين تجميع ReadyToRun ، يجب عليك:

• قم بتعيين الخاصية PublishReadyToRun إلى true .
• نشر باستخدام RuntimeIdentifier صريحة.

ملاحظة: عندما يتم تجميع تجميعات التطبيق ، يكون الكود الأصلي المنتج محددًا للنظام الأساسي والهندسة المعمارية (ولهذا السبب يجب عليك تحديد RuntimeIdentifier صالح عند النشر).

إليك مثال:

 <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project> 

ونشر باستخدام الأمر التالي:

 dotnet publish -r win-x64 -c Release 

ملاحظة: يمكن أيضًا تعيين RuntimeIdentifier في ملف المشروع.

ملاحظة: ReadyToRun معتمد حاليًا فقط للتطبيقات القائمة بذاتها . سيتم تمكينه للتطبيقات المعتمدة على الإطار في معاينة لاحقة.

يمكن تمكين إنشاء الرمز الأصلي عن طريق تعيين الخاصية PublishReadyToRunEmitSymbols إلى true في مشروعك. لا تحتاج إلى إنشاء رموز أصلية لأغراض التصحيح. هذه الرموز مفيدة فقط لأغراض التنميط.

يدعم SDK حاليًا طريقة لاستبعاد بعض التجميعات من التجميع في صور ReadyToRun. قد يكون ذلك مفيدًا للحالات التي لا تحتاج فيها بالفعل بعض المجموعات إلى تحسين الأداء. هذا يمكن أن يساعد في تقليل حجم التطبيق. قد يكون أيضًا حلاً مفيدًا للحالات التي يفشل فيها برنامج التحويل البرمجي ReadyToRun في تجميع تجميع معين. يتم الاستبعاد باستخدام مجموعة عناصر PublishReadyToRunExclude. على سبيل المثال:

 <ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup> 

عبر منصة / مجموعات الهندسة المعمارية

لا يدعم برنامج التحويل البرمجي ReadyToRun الاستهداف المتقاطع حاليًا. تحتاج إلى ترجمة على هدف معين. على سبيل المثال ، إذا كنت تريد صور R2R لنظام التشغيل Windows x 64 ، فأنت بحاجة إلى تشغيل الأمر publish على تلك البيئة.

استثناءات لهذا:

• يمكن استخدام Windows x64 لتجميع صور Windows ARM32 و ARM64 و x86.
• يمكن استخدام Windows x86 لتجميع صور Windows ARM32.
• يمكن استخدام Linux x64 لتجميع صور Linux ARM32 و ARM64.

ربط الجمعية

يأتي .NET SDK 3.0 SDK مع أداة يمكنها تقليل حجم التطبيقات من خلال تحليل IL وتقليم التجميعات غير المستخدمة.

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

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

لاستخدام هذه الأداة ، قم بتعيين PublishTrimmed=true في مشروعك ونشر تطبيق PublishTrimmed=true بذاته:

 dotnet publish -r <rid> -c Release 

سيتضمن إخراج النشر مجموعة فرعية من مكتبات الإطار ، بناءً على ما يستدعي رمز التطبيق. بالنسبة لتطبيق helloworld ، يقلل الرابط من الحجم من 68 ميغابايت إلى 28 ميجابايت تقريبًا.

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

لمزيد من المعلومات حول IL Linker ، راجع الوثائق ، أو قم بزيارة repo أحادي / رابط .

ملاحظة: في الإصدارات السابقة من .NET Core ، تم شحن ILLink.Tasks كحزمة NuGet خارجية وقدمت الكثير من نفس الوظيفة. لم يعد مدعومًا - يرجى التحديث إلى أحدث إصدار 3.0 SDK وتجربة التجربة الجديدة!

باستخدام رابط و ReadToRun معا

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

ملاحظة: يمنع dotnet / sdk # 3257 من استخدام الرابط و ReadyToRun معًا لتطبيقات WPF و Windows Forms. نحن نعمل على إصلاح ذلك كجزء من إصدار .NET Core 3.0.

عينة استضافة الأصلية

نشر الفريق مؤخرًا نموذج الاستضافة الأصلية . يوضح منهج أفضل الممارسات لاستضافة .NET Core في تطبيق أصلي.

كجزء من .NET Core 3.0 ، نعرض الآن الوظائف العامة للمضيفين الأصليين لـ .NET Core والتي كانت متاحة سابقًا فقط للتطبيقات المدارة .NET Core من خلال مضيفي .NET Core المقدمين رسميًا. تتعلق الوظيفة في المقام الأول بالتحميل التجميعي. يجب أن تسهل هذه الوظيفة إنتاج مضيفين أصليين يمكنهم الاستفادة من مجموعة الميزات الكاملة لـ .NET Core.

دعم HTTP / 2 في HttpClient

HTTP / 2 هو مراجعة رئيسية لبروتوكول HTTP. بعض الميزات البارزة في HTTP / 2 هي دعم لضغط الرأس وتدفقات المضاعفات بالكامل عبر نفس الاتصال. بينما يحافظ HTTP / 2 على دلالات HTTP (رؤوس HTTP والأساليب وما إلى ذلك) فهو تغيير من HTTP / 1.x في كيفية تأطير البيانات وإرسالها عبر السلك.

HttpClient الآن إضافة دعم لجعل طلبات HTTP / 2. بينما يبقى الافتراضي HTTP / 1.1 ، يمكنك الاشتراك في استخدام HTTP / 2 عن طريق تعيين الإصدار على رسالة طلب HTTP الخاص بك.

 var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") }; // HTTP/1.1 request using (var response = await client.GetAsync("/")) { Console.WriteLine(response.Content); } // HTTP/2 request using (var request = new HttpRequestMessage(HttpMethod.Get, "/") { Version = new Version(2, 0) }) using (var response = await client.SendAsync(request)) { Console.WriteLine(response.Content); } 

بدلاً من ذلك ، يمكنك افتراضيًا إرسال طلبات HTTP / 2 عن طريق تعيين خاصية DefaultRequestVersion على HttpClient .

 var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) }; // Defaults to HTTP/2 using (var response = await client.GetAsync("/")) { Console.WriteLine(response.Content); } 

نتيجة لهذا التغيير في الإطارات ، تحتاج الخوادم والعملاء إلى التفاوض بشأن إصدار البروتوكول المستخدم. تفاوض بروتوكول طبقة التطبيق (ALPN) هو امتداد TLS يسمح للخادم والعميل بالتفاوض على إصدار البروتوكول المستخدم كجزء من مصافحة TLS. بينما من الممكن أن يكون لديك معرفة مسبقة بين الخادم والعميل على البروتوكول ، فإن معظم الخوادم تدعم ALPN فقط باعتبارها الطريقة الوحيدة لتأسيس اتصال HTTP / 2. على هذا النحو ، يتم التفاوض على HTTP / 2 بواسطة HttpClient فقط على اتصال TLS.

في سيناريوهات التطوير عندما يكون لدى الخادم والعميل معرفة مسبقة بأن كلاهما سيتحدثان HTTP / 2 بدون تشفير ، يمكنك إنشاء اتصال HTTP / 2 عبر نص واضح عن طريق تعيين AppContext التبديل AppContext أو متغير البيئة ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).

 AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true); 

إغلاق

يرجى تجربة الميزات الجديدة. يرجى تقديم مشاكل للبق أو أي تجارب صعبة تجدها. نريد ردود الفعل! يمكنك أيضًا تقديم طلبات لميزات ، لكن من المحتمل أن تحتاج إلى الانتظار حتى يتم تنفيذها حتى الإصدار التالي في هذه المرحلة.

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

في هذه الملاحظة ، سنقوم قريبًا بتبديل الفروع master على .NET Core repos إلى الإصدار الرئيسي التالي ، على الأرجح في أو بعد فترة وجيزة من إصدار Preview 7 (يوليو).

شكرًا لتجربة معاينات .NET Core 3.0. نحن نقدر مساعدتك. في هذه المرحلة ، نحن نركز على الحصول على الإصدار النهائي بين يديك.