Visual-Studio | The .NET Blog

أدوات Azure MCP مدمجة الآن في Visual Studio 2022 — لا حاجة إلى امتداد

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

إذا كنت تستخدم أدوات Azure MCP في Visual Studio من خلال الامتداد المنفصل، فأنت تعرف العملية — تثبيت VSIX، إعادة التشغيل، والأمل ألا ينكسر، وإدارة تعارضات الإصدارات. لقد اختفى هذا الاحتكاك.

أعلنت Yun Jung Choi أن أدوات Azure MCP تُشحن الآن مباشرةً كجزء من حمل عمل تطوير Azure في Visual Studio 2022. بدون امتداد. بدون VSIX. بدون رقصة إعادة التشغيل.

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

ابتداءً من Visual Studio 2022 الإصدار 17.14.30، يأتي Azure MCP Server مجمّعاً مع حمل عمل تطوير Azure. إذا كان حمل العمل هذا مثبتاً بالفعل، فتحتاج فقط إلى تفعيله في GitHub Copilot Chat وستنتهي.

أكثر من 230 أداة عبر 45 خدمة Azure — متاحة مباشرةً من نافذة الدردشة. سرّد حسابات التخزين لديك، انشر تطبيق ASP.NET Core، شخّص مشاكل App Service، استعلم Log Analytics — كل ذلك دون فتح أي علامة تبويب في المتصفح.

لماذا هذا أهم مما يبدو

إليك الأمر في أدوات المطورين: كل خطوة إضافية هي احتكاك، والاحتكاك يقتل الاستخدام. وجود MCP كامتداد منفصل كان يعني تعارض الإصدارات وفشل التثبيت وشيء آخر لتبقيه محدثاً. إدماجه في نظام حمل العمل يعني:

مسار تحديث واحد عبر Visual Studio Installer
لا انجراف في الإصدارات بين الامتداد وبيئة التطوير المتكاملة
دائماً حديث — يتحدث MCP Server مع إصدارات VS المنتظمة

بالنسبة للفرق التي تعتمد معياراً على Azure، هذا أمر مهم. تثبّت حمل العمل مرة واحدة، تفعّل الأدوات، وتكون موجودة في كل جلسة.

ما الذي يمكنك فعله به

تغطي الأدوات دورة التطوير الكاملة من خلال Copilot Chat:

التعلم — اسأل عن خدمات Azure وأفضل الممارسات وأنماط البنية
التصميم والتطوير — احصل على توصيات الخدمة وضبط كود التطبيق
النشر — زوّد الموارد وانشر مباشرةً من بيئة التطوير المتكاملة
استكشاف الأخطاء — استعلم السجلات وتحقق من صحة الموارد وشخّص مشاكل الإنتاج

مثال سريع — اكتب هذا في Copilot Chat:

List my storage accounts in my current subscription.

يستدعي Copilot أدوات Azure MCP في الخلفية، ويستعلم اشتراكاتك، ويعيد قائمة منسقة بالأسماء والمواقع وحيازات SKU. لا حاجة إلى البوابة الإلكترونية.

كيفية التفعيل

حدّث إلى Visual Studio 2022 17.14.30 أو أحدث
تأكد من تثبيت حمل عمل Azure development
افتح GitHub Copilot Chat
انقر على زر Select tools (أيقونة المفكَّين)
فعّل Azure MCP Server

هذا كل شيء. يبقى مفعّلاً عبر الجلسات.

تحفظ واحد

الأدوات معطلة افتراضياً — تحتاج إلى الاشتراك الصريح. والأدوات الخاصة بـ VS 2026 غير متاحة في VS 2022. كما يعتمد توافر الأدوات على أذونات اشتراك Azure لديك، تماماً كما في البوابة الإلكترونية.

الصورة الأكبر

هذا جزء من اتجاه واضح: يصبح MCP الطريقة المعيارية لعرض أدوات السحابة في بيئات تطوير المطورين. رأينا بالفعل إصدار Azure MCP Server 2.0 المستقر وتكاملات MCP عبر VS Code والمحررات الأخرى. دمجه في نظام حمل العمل في Visual Studio هو التطور الطبيعي.

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

إعداد النوافذ العائمة في Visual Studio الذي لم تكن تعرفه (لكنك يجب أن تعرفه)

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

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

شارك Mads Kristensen من فريق Visual Studio إعداداً غير معروف يغير كلياً طريقة تصرف النوافذ العائمة. قائمة منسدلة واحدة. هذا كل شيء.

الإعداد

Tools > Options > Environment > Windows > Floating Windows

تحتوي القائمة المنسدلة “These floating windows are owned by the main window” على ثلاثة خيارات:

None — استقلالية كاملة. كل نافذة عائمة تحصل على إدخالها الخاص في شريط المهام وتتصرف كنافذة Windows عادية.
Tool Windows (الافتراضي) — تطفو المستندات بحرية، وتظل نوافذ الأدوات مرتبطة ببيئة التطوير.
Documents and Tool Windows — السلوك الكلاسيكي لـ Visual Studio، كل شيء مرتبط بالنافذة الرئيسية.

لماذا يُعدّ “None” الخيار الأمثل مع الشاشات المتعددة

اضبطه على None وستتصرف جميع نوافذ الأدوات العائمة والمستندات فجأة كتطبيقات Windows حقيقية. تظهر في شريط المهام، وتبقى مرئية عند تصغير نافذة Visual Studio الرئيسية، وتتوقف عن إجبار نفسها إلى مقدمة كل شيء.

ادمج هذا مع PowerToys FancyZones ويصبح الأمر مغيّراً لقواعد اللعبة. أنشئ تخطيطات مخصصة عبر شاشاتك، وثبّت Solution Explorer في منطقة، ومنقّح الأخطاء في أخرى، وملفات الكود أينما تريد. كل شيء يبقى في مكانه، وكل شيء يمكن الوصول إليه باستقلالية، ويشعر مساحة عملك بالتنظيم بدلاً من الفوضى.

توصيات سريعة

مستخدمو الشاشات المتعددة: اضبط على None، وادمجه مع FancyZones
المستخدمون العرضيون للنوافذ العائمة: Tool Windows (الافتراضي) خيار وسط جيد
سير العمل التقليدي: Documents and Tool Windows يحافظ على كل شيء كلاسيكياً

نصيحة احترافية: Ctrl + نقر مزدوج على شريط عنوان أي نافذة أداة لتعويمها أو إرسائها فوراً. لا يلزم إعادة تشغيل بعد تغيير الإعداد.

خلاصة القول

إنه أحد تلك الإعدادات التي تجعلك تفكر “لا أصدق أنني لم أكن أعرف عن هذا”. إذا كانت النوافذ العائمة في Visual Studio قد أزعجتك يوماً، فاذهب وغيّر هذا الإعداد الآن.

اقرأ المقال الكامل للتفاصيل ولقطات الشاشة.

Bookmark Studio يُضيف نظام التنقل بالفتحات والمشاركة إلى إشارات Visual Studio المرجعية

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

الإشارات المرجعية في Visual Studio كانت دومًا… مقبولة. تضع إشارة، تنتقل إلى التالية، ثم تنسى أيها أيها. تؤدي وظيفتها، لكنها لم تكن يومًا الميزة التي تصفها بالقوية.

أصدر Mads Kristensen للتو Bookmark Studio، وهي إضافة تجريبية تسد بالضبط الفجوات التي ربما اصطدمت بها إذا كنت تستخدم الإشارات المرجعية بانتظام.

التنقل بالفتحات

الإضافة الأساسية: يمكن الآن تعيين الإشارات المرجعية إلى فتحات من 1 إلى 9 والقفز إليها مباشرةً بـ Alt+Shift+1 حتى Alt+Shift+9. تحصل الإشارات الجديدة تلقائيًا على الفتحة المتاحة التالية، لذا يعمل التنقل السريع في معظم الحالات دون أي إعداد.

قد يبدو هذا بسيطًا، لكنه يحوّل الإشارات المرجعية من “لديّ بعض الإشارات في مكان ما” إلى “الفتحة 3 هي وحدة التحكم API، الفتحة 5 هي طبقة الخدمة، الفتحة 7 هي الاختبار.” هذا النوع من التنظيم المكاني يجعل التنقل شبه فوري خلال جلسات العمل المركّز.

مدير الإشارات المرجعية

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

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

التنظيم بالتسميات والألوان والمجلدات

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

جميع البيانات الوصفية تُخزَّن لكل حل (solution)، لذا يظل تنظيم إشاراتك المرجعية محفوظًا عبر الجلسات.

التصدير والمشاركة

هذه هي الميزة التي لم أكن أعلم أنني أريدها. يتيح لك Bookmark Studio تصدير الإشارات المرجعية كنص عادي أو Markdown أو CSV. هذا يعني أنك تستطيع:

تضمين مسارات الإشارات في أوصاف طلبات السحب
مشاركة مسارات التحقيق مع زملاء الفريق
نقل مجموعات الإشارات بين المستودعات أو الفروع

تتحول الإشارات المرجعية من أداة تنقل فردية إلى وسيلة للتواصل قائلًا “إليك المسار عبر هذا الكود.”

إشارات مرجعية تتتبع حركة الكود

يتتبع Bookmark Studio الإشارات المرجعية بالنسبة للنص المرتبطة به، لذا لا تنزلق إلى سطور خاطئة بينما تُحرِّر الكود. إذا سبق لك أن وضعت إشارات خلال جلسة تصحيح أخطاء ثم وجدتها كلها تشير إلى سطور خاطئة بعد عملية إعادة هيكلة — هذا يحل تلك المشكلة.

خلاصة

لا يُعيد Bookmark Studio اختراع أي شيء. بل يأخذ ميزة كانت “كافية” لسنوات ويجعلها مفيدة حقًا للتطوير المركّز. التنقل بالفتحات ومدير الإشارات المرجعية وإمكانيات التصدير هي أبرز ما يقدمه.

احصل عليه من Visual Studio Marketplace وجرّبه.

تحديث Visual Studio لشهر مارس يتيح لك بناء وكلاء Copilot مخصصين — وأداة find_symbol تستحق الاهتمام

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

حصل Visual Studio للتو على أهم تحديث لـ Copilot حتى الآن. أعلن Mark Downie عن إصدار مارس، والعنوان الرئيسي هو الوكلاء المخصصون — لكن بصراحة، أداة find_symbol المدفونة في منتصف القائمة قد تكون الميزة التي ستغير سير عملك أكثر من أي شيء آخر.

دعني أشرح ما هو موجود فعلاً.

وكلاء Copilot مخصصون في مستودعك

هل تريد أن يتبع Copilot معايير ترميز فريقك، أو يشغّل خط أنابيب البناء، أو يستعلم وثائقك الداخلية؟ يمكنك الآن بناء ذلك بالضبط.

يُعرَّف الوكلاء المخصصون كملفات .agent.md تضعها في .github/agents/ في مستودعك. يتمتع كل وكيل بوصول كامل إلى الوعي بمساحة العمل، وفهم الكود، والأدوات، ونموذجك المفضل، واتصالات MCP بالخدمات الخارجية. تظهر هذه الوكلاء في منتقي الوكلاء إلى جانب الوكلاء المدمجين.

هذا النمط ذاته الذي كان VS Code يدعمه — ومن الجيد رؤية Visual Studio يلحق به. إذا كانت فرقتك قد بنت وكلاء لـ VS Code، فينبغي أن تعمل ملفات .agent.md عبر كلا بيئتَي التطوير (مع ذلك، قد تتباين أسماء الأدوات، لذا اختبرها).

يحتوي مستودع awesome-copilot على إعدادات وكلاء يُسهم بها المجتمع يمكنك استخدامها نقطة انطلاق.

مهارات الوكيل: حزم تعليمات قابلة لإعادة الاستخدام

يتم التقاط المهارات تلقائياً من .github/skills/ في مستودعك أو ~/.copilot/skills/ في ملفك الشخصي. كل مهارة هي ملف SKILL.md يتبع مواصفات Agent Skills.

فكّر في المهارات كخبرات معيارية يمكنك دمجها وتبديلها. قد تكون لديك مهارة لاصطلاحات API الخاصة بك، وأخرى لأنماط الاختبار، وأخرى لسير عمل النشر. عندما تنشط مهارة، تظهر في المحادثة حتى تعرف أنها مُطبَّقة.

إذا كنت تستخدم المهارات في VS Code، فهي تعمل بالطريقة ذاتها في Visual Studio الآن.

find_symbol: ملاحة رمزية تدرك اللغة للوكلاء

هنا تصبح الأمور مثيرة للاهتمام حقاً. تمنح أداة find_symbol الجديدة وضعَ وكيل Copilot ملاحةً رمزية فعلية مدعومة بخدمة اللغة. بدلاً من البحث في كودك كنص عادي، يمكن للوكيل:

إيجاد جميع المراجع لرمز عبر مشروعك
الوصول إلى معلومات النوع والإعلانات وبيانات النطاق
التنقل عبر مواقع الاستدعاء بوعي كامل باللغة

ما يعنيه هذا عملياً: عندما تطلب من Copilot إعادة هيكلة طريقة أو تحديث توقيع معامل عبر مواقع الاستدعاء، يمكنه فعلاً رؤية بنية كودك. لا مزيد من “قام الوكيل بتغيير الطريقة لكنه فاته ثلاثة مواقع استدعاء”.

اللغات المدعومة تشمل C# وC++ وRazor وTypeScript وأي لغة تتوفر لها إضافة LSP مدعومة. لمطوري .NET، هذا تحسين جوهري — قواعد كود C# ذات التسلسلات الهرمية العميقة للأنواع والواجهات تستفيد استفادة هائلة من الملاحة الرمزية.

تحليل أداء الاختبارات مع Copilot

يوجد الآن أمر Profile with Copilot في قائمة سياق Test Explorer. حدد اختباراً، انقر على التحليل، ويقوم وكيل التحليل تلقائياً بتشغيله وتحليل الأداء — يجمع بين بيانات استخدام المعالج وبيانات القياس لتقديم رؤى قابلة للتنفيذ.

لا مزيد من الإعداد اليدوي لجلسات المحلل، وتشغيل الاختبار، وتصدير النتائج، ومحاولة قراءة رسم بياني للهوية. يقوم الوكيل بالتحليل ويخبرك بما هو بطيء ولماذا. خاص بـ .NET حالياً، وهو أمر منطقي نظراً للتكامل العميق لـ Visual Studio مع أدوات تشخيص .NET.

نصائح الأداء أثناء التصحيح المباشر

أصبح تحسين الأداء يحدث أثناء التصحيح، لا بعده. بينما تتنقل خطوة بخطوة عبر الكود، يعرض Visual Studio وقت التنفيذ وإشارات الأداء بشكل مضمّن. هل ترى سطراً بطيئاً؟ انقر على Perf Tip واطلب من Copilot اقتراحات للتحسين في المكان ذاته.

يلتقط وكيل التحليل بيانات وقت التشغيل تلقائياً — الوقت المنقضي واستخدام المعالج وسلوك الذاكرة — ويستخدمها Copilot لتحديد مناطق الاختناق. هذا يجعل عمل الأداء جزءاً من سير عمل التصحيح بدلاً من مهمة منفصلة تؤجلها باستمرار.

إصلاح ثغرات NuGet من Solution Explorer

عندما تُكتشف ثغرة في حزمة NuGet، يظهر الآن إشعار مع رابط Fix with GitHub Copilot مباشرةً في Solution Explorer. انقر عليه ويحلل Copilot الثغرة، ويوصي بتحديثات الحزمة المناسبة، وينفّذها.

للفرق التي تكافح للحفاظ على تحديث التبعيات (وهو ما يصف الجميع تقريباً)، يُزيل هذا احتكاك “أعرف أن هناك ثغرة لكن معرفة مسار التحديث الصحيح مشروع بحد ذاته.”

خلاصة القول

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

قم بتنزيل Visual Studio 2026 Insiders لتجربة كل ذلك.

VS Code 1.112: ما يهمك فعلاً كمطور .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

وصل VS Code 1.112 للتو، وبصراحة؟ هذا الإصدار مختلف إذا كنت تقضي أيامك في عالم .NET. يوجد الكثير في ملاحظات الإصدار الرسمية، لكن دعني أوفر عليك التمرير وأركز على ما يهم فعلاً بالنسبة لنا.

Copilot CLI أصبح أكثر فائدة بكثير

الموضوع الرئيسي لهذا الإصدار هو استقلالية الوكيل — إعطاء Copilot مساحة أكبر للعمل دون مراقبة كل خطوة.

توجيه الرسائل وإضافتها إلى قائمة الانتظار

هل تعرف تلك اللحظة التي يكون فيها Copilot CLI في منتصف مهمة وتدرك أنك نسيت ذكر شيء ما؟ في السابق، كان عليك الانتظار. الآن يمكنك إرسال رسائل أثناء تشغيل طلب — إما لتوجيه الاستجابة الحالية أو لوضع تعليمات المتابعة في قائمة الانتظار.

هذا رائع لمهام السقالات الطويلة باستخدام dotnet حيث تشاهد Copilot يُعدّ مشروعاً وتفكر “آه، أريد أيضاً MassTransit في هذا.”

مستويات الأذونات

هذا الأكثر إثارة لاهتمامي. تدعم جلسات Copilot CLI الآن ثلاثة مستويات أذونات:

Default Permissions — التدفق المعتاد حيث تطلب الأدوات التأكيد قبل التشغيل
Bypass Approvals — يوافق تلقائياً على كل شيء ويعيد المحاولة عند الأخطاء
Autopilot — يعمل باستقلالية كاملة: يوافق على الأدوات، ويجيب على أسئلته الخاصة، ويستمر حتى الانتهاء من المهمة

إذا كنت تُنشئ سقالة لـ ASP.NET Core API جديدة مع Entity Framework والترحيلات وإعداد Docker — فوضع Autopilot يعني أنك تصف ما تريد ثم تذهب لتحضير قهوة. سيعرف كيف يُنجز المهمة.

يمكنك تمكين Autopilot بإعداد chat.autopilot.enabled.

معاينة التغييرات قبل التفويض

عندما تفوّض مهمة لـ Copilot CLI، يُنشئ worktree. في السابق، إذا كان لديك تغييرات غير مُودَعة، كان عليك مراجعة Source Control لمعرفة ما سيتأثر. الآن يعرض عرض Chat التغييرات المعلّقة مباشرةً قبل أن تقرر ما إذا كنت تريد نسخها أو نقلها أو تجاهلها.

أمر بسيط، لكنه يجنّبك لحظة “انتظر، ماذا كان لديّ في منطقة الإعداد؟”

تصحيح تطبيقات الويب دون مغادرة VS Code

يدعم المتصفح المدمج الآن التصحيح الكامل. يمكنك تعيين نقاط التوقف والتنقل خطوة بخطوة وفحص المتغيرات — كل ذلك داخل VS Code. لا مزيد من التبديل إلى Edge DevTools.

يوجد نوع تصحيح جديد editor-browser، وإذا كانت لديك تكوينات تشغيل msedge أو chrome موجودة، فالترحيل بسيط كتغيير حقل type في launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

لمطوري Blazor، هذا تغيير جذري. أنت بالفعل تشغّل dotnet watch في الطرفية — الآن يبقى التصحيح في نفس النافذة أيضاً.

حصل المتصفح أيضاً على مستويات تكبير مستقلة (أخيراً)، وقوائم سياق صحيحة بنقر يمين، ويُحفظ التكبير لكل موقع على حدة.

عزل خادم MCP في صندوق رمل

هذا أهم مما تعتقد. إذا كنت تستخدم خوادم MCP — ربما أعددت خادماً مخصصاً لموارد Azure أو استعلامات قاعدة البيانات — فقد كانت تعمل بنفس أذونات عملية VS Code. هذا يعني وصولاً كاملاً إلى نظام الملفات والشبكة وكل شيء.

الآن يمكنك عزلها في صندوق رمل. في ملف mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

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

ملاحظة: العزل في صندوق الرمل متاح على macOS وLinux حالياً. دعم Windows قادم — سيناريوهات التشغيل عن بُعد مثل WSL تعمل بالفعل.

اكتشاف تخصيصات Monorepo

إذا كنت تعمل في monorepo (ولنكن صادقين، كثير من مشاريع .NET المؤسسية تصبح كذلك في نهاية المطاف)، فهذا يحل نقطة ألم حقيقية.

في السابق، إذا فتحت مجلداً فرعياً من مستودعك، لن يجد VS Code ملف copilot-instructions.md أو AGENTS.md أو المهارات المخصصة الموجودة في جذر المستودع. الآن مع إعداد chat.useCustomizationsInParentRepositories، يصعد إلى جذر .git ويكتشف كل شيء.

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

/troubleshoot لتصحيح أخطاء الوكيل

هل سبق أن أعددت تعليمات أو مهارات مخصصة وتساءلت لماذا لا يتم التقاطها؟ مهارة /troubleshoot الجديدة تقرأ سجلات تصحيح الوكيل وتخبرك بما حدث — أي الأدوات استُخدمت أو تجاوزت، ولماذا لم يُحمَّل التعليمات، وما الذي يتسبب في بطء الاستجابات.

مكّنها بـ:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

ثم اكتب /troubleshoot لماذا لا تُحمَّل مهارتي المخصصة؟ في المحادثة.

يمكنك أيضاً تصدير هذه السجلات واستيرادها الآن، وهو أمر رائع لمشاركتها مع فريقك عندما لا يعمل شيء كما هو متوقع.

دعم الصور والملفات الثنائية

يمكن للوكلاء الآن قراءة ملفات الصور من القرص والملفات الثنائية بشكل أصلي. تُعرض الملفات الثنائية بتنسيق hexdump، ومخرجات الصور (مثل لقطات الشاشة من المتصفح المدمج) تظهر في عرض دوّار.

لمطوري .NET، فكّر في: لصق لقطة شاشة لخطأ في واجهة المستخدم في المحادثة وطلب من الوكيل فهم ما الخطأ، أو تحليل مخرجات مكوّن Blazor.

المراجع الرمزية التلقائية

تحسين بسيط لجودة الحياة: عندما تنسخ اسم رمز (فئة أو طريقة وما إلى ذلك) وتلصقه في المحادثة، يحوّله VS Code الآن تلقائياً إلى مرجع #sym:Name. هذا يمنح الوكيل السياق الكامل عن هذا الرمز دون الحاجة لإضافته يدوياً.

إذا أردت نصاً عادياً بدلاً من ذلك، استخدم Ctrl+Shift+V.

تمكين/تعطيل الإضافات

في السابق، تعطيل خادم MCP أو إضافة كان يعني إلغاء تثبيته. الآن يمكنك تبديل تشغيلهم وإيقافهم — عالمياً وفي كل مساحة عمل على حدة. انقر يمين في عرض Extensions أو عرض Customizations وانتهى الأمر.

الإضافات من npm وpypi يمكنها أيضاً التحديث التلقائي الآن، وإن كانت ستطلب الموافقة أولاً لأن التحديثات تعني تشغيل كود جديد على جهازك.

خلاصة القول

يدفع VS Code 1.112 بقوة نحو تجربة الوكيل — استقلالية أكبر، وتصحيح أفضل، وأمان أكثر إحكاماً. لمطوري .NET، التصحيح عبر المتصفح المدمج وتحسينات Copilot CLI هي الميزات البارزة.

إذا لم تجرّب بعد تشغيل جلسة Copilot CLI كاملة في وضع Autopilot لمشروع .NET، فهذا الإصدار هو الوقت المناسب للبدء. فقط تذكر ضبط أذوناتك ودعه يعمل.

قم بتنزيل VS Code 1.112 أو التحديث من داخل VS Code عبر Help > Check for Updates.