Developer Tooling | The .NET Blog

azd + GitHub Copilot: إعداد المشروع بالذكاء الاصطناعي وحل الأخطاء بذكاء

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

تُرجِمت هذه المقالة تلقائيًا. للاطلاع على النسخة الأصلية بالإنجليزية، انقر هنا.

هل تعرف تلك اللحظة التي تريد فيها نشر تطبيق موجود على Azure فتجد نفسك تحدق في ملف azure.yaml فارغ، محاولًا تذكر ما إذا كان Express API الخاص بك يجب أن يستخدم Container Apps أم App Service؟ تلك اللحظة أصبحت الآن أقصر بكثير.

يتكامل Azure Developer CLI (azd) الآن مع GitHub Copilot بطريقتين عمليتين: سقالة المشروع بمساعدة الذكاء الاصطناعي خلال azd init، واستكشاف الأخطاء وإصلاحها بذكاء عند فشل عمليات النشر. كلا الميزتين تعملان بالكامل داخل الطرفية.

الإعداد مع Copilot أثناء azd init

عند تشغيل azd init، يظهر الآن خيار “Set up with GitHub Copilot (Preview)”. اختره وسيحلل Copilot قاعدة التعليمات البرمجية الخاصة بك لإنشاء azure.yaml وقوالب البنية التحتية ووحدات Bicep — بناءً على الكود الفعلي.

azd init
# اختر: "Set up with GitHub Copilot (Preview)"

المتطلبات:

azd 1.23.11 أو أحدث — تحقق بـ azd version أو حدّث بـ azd update
اشتراك نشط في GitHub Copilot (فردي أو للأعمال أو للمؤسسات)
GitHub CLI (gh) — سيطلب azd تسجيل الدخول إذا لزم الأمر

ما أجده مفيدًا حقًا: يعمل في الاتجاهين. تبني من الصفر؟ يساعدك Copilot على تهيئة خدمات Azure الصحيحة من البداية. لديك تطبيق موجود تريد نشره؟ وجّه Copilot إليه وسيُنشئ التهيئة دون الحاجة إلى إعادة هيكلة أي شيء.

ما الذي يفعله فعليًا

لنفترض أن لديك Node.js Express API يعتمد على PostgreSQL. بدلًا من اتخاذ قرار يدوي بين Container Apps وApp Service ثم كتابة Bicep من الصفر، يكتشف Copilot تقنياتك ويُنشئ:

azure.yaml بالإعدادات الصحيحة لـ language وhost وbuild
وحدة Bicep لـ Azure Container Apps
وحدة Bicep لـ Azure Database for PostgreSQL

ويُجري فحوصات مسبقة قبل تغيير أي شيء — يتحقق من نظافة دليل git، ويطلب موافقتك على أدوات خادم MCP مسبقًا. لا شيء يحدث دون علمك بما سيتغير بالضبط.

استكشاف الأخطاء وإصلاحها مع Copilot

أخطاء النشر لا مفر منها. معاملات مفقودة، مشكلات في الأذونات، توفر SKU — ونادرًا ما تخبرك رسالة الخطأ بالشيء الوحيد الذي تحتاج معرفته فعلًا: كيف تُصلحه.

بدون Copilot، الحلقة تبدو هكذا: انسخ الخطأ ← ابحث في المستندات ← اقرأ ثلاث إجابات Stack Overflow غير ذات صلة ← شغّل بعض أوامر az CLI ← أعد المحاولة وتمنَّ. مع Copilot في azd، تنهار هذه الحلقة. عند فشل أي أمر azd، يعرض فورًا أربعة خيارات:

Explain — شرح بلغة مبسطة لما حدث
Guidance — تعليمات خطوة بخطوة لإصلاح المشكلة
Diagnose and Guide — تحليل كامل + يطبق Copilot الإصلاح (بموافقتك) + إعادة محاولة اختيارية
Skip — التعامل معه بنفسك

النقطة الرئيسية: لدى Copilot بالفعل سياق مشروعك والأمر الفاشل وتفاصيل الخطأ. اقتراحاته خاصة بـ وضعك.

ضبط السلوك الافتراضي

إذا كنت دائمًا تختار نفس الخيار، تجاوز الموجه التفاعلي:

azd config set copilot.errorHandling.category troubleshoot

القيم: explain وguidance وtroubleshoot وfix وskip. يمكنك أيضًا تمكين الإصلاح التلقائي وإعادة المحاولة:

azd config set copilot.errorHandling.fix allow

العودة إلى الوضع التفاعلي في أي وقت:

azd config unset copilot.errorHandling.category

خاتمة

شغّل azd update للحصول على أحدث إصدار وجرّب azd init في مشروعك القادم.

اقرأ الإعلان الأصلي هنا.

كتابة إضافات Node.js الأصلية بلغة C# مع .NET Native AOT

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

تُرجِمت هذه المقالة تلقائيًا. للاطلاع على النسخة الأصلية بالإنجليزية، انقر هنا.

إليك سيناريو أحبه: فريق يعمل على أدوات .NET كان لديه إضافات Node.js أصلية مكتوبة بـ C++ ومُجمَّعة عبر node-gyp. كانت تعمل. لكنها كانت تتطلب تثبيت Python على كل جهاز مطوّر — إصدارًا قديمًا من Python — فقط لتجميع حزمة لن يمسّها أحد في الفريق مباشرةً.

فطرحوا سؤالًا معقولًا جدًا: لدينا .NET SDK مثبّت بالفعل، لماذا نكتب C++ أصلًا؟

كانت الإجابة هي Native AOT، والنتيجة أنيقة حقًا. كتب Drew Noakes من فريق C# Dev Kit كيفية القيام بذلك.

الفكرة الأساسية

إضافة Node.js الأصلية هي مكتبة مشتركة (.dll على Windows، .so على Linux، .dylib على macOS) يمكن لـ Node.js تحميلها في وقت التشغيل. الواجهة تُسمى N-API — واجهة برمجة تطبيقات C مستقرة ومتوافقة مع ABI. لا يهتم N-API بالغة التي أنتجت المكتبة، فقط أن تُصدِّر الرموز الصحيحة.

يمكن لـ .NET Native AOT تحقيق ذلك تمامًا. يُجمِّع كود C# مسبقًا إلى مكتبة مشتركة أصلية بنقاط دخول اختيارية.

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

ملف المشروع في أدنى حد:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot يُخبر SDK بإنتاج مكتبة مشتركة عند dotnet publish.

تصدير نقطة الدخول

يتوقع Node.js أن تُصدِّر مكتبتك napi_register_module_v1. في C#، [UnmanagedCallersOnly] يفعل ذلك تمامًا:

[UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
}

اللاحقة u8 تُنتج ReadOnlySpan<byte> مع قيمة حرفية للسلسلة UTF-8، مُمرَّرة مباشرةً إلى N-API دون أي تخصيص ترميز.

حل N-API مقابل العملية المضيفة

تُصدَّر دوال N-API من node.exe نفسه، وليس من مكتبة منفصلة. لذا بدلًا من الربط بشيء ما، تحلّها مقابل العملية الجارية عند بدء التشغيل:

NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

مع ذلك، تعمل إعلانات P/Invoke بشكل نظيف:

[LibraryImport("node", EntryPoint = "napi_create_string_utf8")]
internal static partial Status CreateStringUtf8(
 nint env, ReadOnlySpan<byte> str, nuint length, out nint result);

استدعاؤه من TypeScript

يُنتج dotnet publish مكتبتك الأصلية الخاصة بالمنصة. غيّر اسمها إلى .node واستخدمها مع require() القياسي:

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

هذا كل شيء. من TypeScript إلى C#، بدون Python، بدون C++.

خلاصة

استبدل فريق C# Dev Kit عبء Python/C++ بكود C# نظيف يعرف كل شخص في الفريق كيفية كتابته وتصحيحه. النمط ليس معقدًا بمجرد رؤيته، وهو مثال رائع على Native AOT يحل مشكلة حقيقية لا تُناقش بما فيه الكفاية.

اقرأ المقالة الأصلية على مدونة .NET.