Performance | The .NET Blog

‎.NET 11 يصلح أخيرًا واجهة برمجة تطبيقات العمليات

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

كل مطور .NET احتاج إلى إطلاق عملية والتقاط مخرجاتها قد كتب نوعًا من الكود النمطي الخطير نفسه: قراءة غير متزامنة من stdout، وقراءة غير متزامنة من stderr، وWaitForExitAsync، مع عدم نسيان إفراغ كلا التيارين وإلا ستواجه إغلاقًا ميتًا. إنه فخ معروف موجود منذ سنوات.

‎.NET 11 يصلح هذا أخيرًا بشكل صحيح.

RunAndCaptureTextAsync

الإضافة الرئيسية: طريقة ثابتة واحدة تبدأ عملية، وتلتقط stdout وstderr، وتنتظر الإنهاء دون إغلاق ميت.

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

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

هناك أيضًا Process.RunAsync للحالة التي تريد فيها الانتظار حتى الإنهاء دون التقاط المخرجات.

KillOnParentExit

مشكلة شائعة مع العمليات المُطلقة: إذا تعطل الوالد أو أُنهي، تستمر العمليات الفرعية في التشغيل كأيتام. يتيح لك KillOnParentExit الإعلان عند بدء العملية بأن العملية الفرعية يجب إنهاؤها عند إنهاء العملية الوالدة.

هذه ميزة كانت موجودة بطرق خاصة بالمنصة (كائنات المهام على Windows، وprctl على Linux) لكنها كانت تتطلب p/invoke أو مكتبات طرف ثالث للاستخدام من .NET. الآن أصبحت خاصية من الدرجة الأولى على ProcessStartInfo.

واجهات API المستندة إلى SafeProcessHandle

سطح API الخفيف الجديد مبني حول SafeProcessHandle بدلاً من الفئة Process الكاملة. الفئة Process الكاملة تحمل الكثير من الحالة وصعبة التقليص — مسار SafeProcessHandle أكثر توافقًا مع المُقلِّص للتطبيقات التي تحتاج إلى تصغير حجم المخرجات (WASM، AOT الأصلي).

تحكم كامل في وراثة المقابض

يضيف التحديث أيضًا تحكمًا دقيقًا في المقابض التي يرثها العملية الفرعية وكيفية إعادة توجيه المقابض القياسية. في السابق كان بإمكانك إعادة توجيه stdin/stdout/stderr لكن لم يكن بإمكانك تحديد المقابض التي ترث بالضبط على مستوى نظام التشغيل. تعرض واجهات برمجة التطبيقات الجديدة هذا التحكم.

لماذا هذا مهم

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

للتطبيقات المُقلَّصة أو سيناريوهات الترجمة AOT، يُرحَّب بشكل خاص بمسار SafeProcessHandle. كانت فئة Process القديمة تجلب الكثير من الكود كثيف الانعكاسات الذي كان يعقّد التقليص.

المنشور الأصلي: Process API Improvements in .NET 11

كيف انتقل Copilot Studio إلى .NET 10 WebAssembly وأصبح أسرع بنسبة 20%

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

قام فريق Copilot Studio بشيء كان فضوليًا بشأنه جميع مطوري Blazor WASM: لقد قاموا فعليًا بترقية تطبيق إنتاجي من .NET 8 إلى .NET 10 وقاسوا النتائج. يشارك المنشور أرقامًا محددة، وهو أمر نادر ومفيد حقًا.

الترقية كانت مملة (هذا أمر جيد)

تحديث إطار العمل المستهدف، تحديث مراجع الحزم، إصلاح التغييرات المخلة. هذا كل شيء. بناء .NET 10 يعمل الآن في الإنتاج. الهجرة نفسها لم تكن الجزء المثير للاهتمام — التغييرات في .NET 10 هي ذلك.

البصمة التلقائية للأصول

في السابق، كان توزيع تطبيق WASM يعني كتابة نصوص برمجية مخصصة لإعادة تسمية الأصول المنشورة بتجزئات SHA256 لتجاوز التخزين المؤقت. كان لدى Copilot Studio نص PowerShell يقوم بهذا بالضبط — إعادة تسمية الملفات، حقن سمات integrity في محمّل JavaScript، إدارة كل شيء يدويًا.

في .NET 10، كل ذلك مدمج. يتم وضع بصمة تلقائية على الأصول المنشورة، واستيرادها مباشرة من dotnet.js، والتحقق من سلامتها دون تدخل يدوي. قام الفريق بحذف نص إعادة التسمية.

تغيير صغير في النطاق، تخفيض كبير في التعقيد.

WasmStripILAfterAOT مفعّل الآن افتراضيًا

في .NET 8، كان إزالة IL من التجميعات المترجمة بـ AOT اختياريًا. في .NET 10 هو السلوك الافتراضي. بعد ترجمة AOT، يتم إزالة رمز IL الأصلي من المخرجات — غير مطلوب في وقت التشغيل، والاحتفاظ به كان يضخم حجم الحزمة دون سبب.

يستخدم Copilot Studio تحسينًا محددًا: يوزع كلًا من محرك JIT (بدء سريع) ومحرك AOT (أقصى أداء في الحالة الثابتة)، يحمّل كليهما بالتوازي وينتقل من JIT إلى AOT بمجرد استعداده. كما يُزيل تكرار الملفات المتطابقة بين المحركَين.

يعني سلوك إزالة IL الجديد أن تجميعات AOT لم تعد تطابق نظيراتها من JIT بشكل بت ببت، لذا تُزال تكرارات ملفات أقل:

.NET 8: 59 ملفًا مشتركًا
.NET 10: 22 ملفًا مشتركًا

النتيجة الصافية: حجم حزمة أكبر بحوالي 15% لمحرك AOT. تنزيل AOT أبطأ بحوالي 6% على شبكة LAN السريعة، وأبطأ بحوالي 17% على 4G. لكن كل ذلك يحدث في الخلفية بعد أن يصبح التطبيق تفاعليًا بالفعل.

أرقام الأداء

هذا هو الجزء المهم:

أسرع بحوالي 20% في المكالمة الأولى (المسار البارد)
أسرع بحوالي 5% في المكالمات اللاحقة (المسار الدافئ)

التحسينات أكثر وضوحًا في “البوتات الكبيرة” — العملاء الكبيرة والمعقدة حيث يهيمن الكود المترجم بـ AOT. لسير العمل الأبسط، الكسب أصغر.

إذا كنت لا تزال على .NET 8

قصة الهجرة بسيطة بحق: حدّث <TargetFramework>، حدّث مراجع الحزم، احذف أي نصوص بصمة مخصصة، وستستفيد تلقائيًا من WasmStripILAfterAOT. إذا كنت تترجم بـ AOT، توقع مكاسب مماثلة في الأداء.

ملاحظة من المنشور: إذا كنت تحمّل وقت تشغيل .NET WASM داخل WebWorker، اضبط dotnetSidecar = true عند التهيئة.

المنشور الأصلي: Copilot Studio gets faster with .NET 10 on WebAssembly