Productivity | The .NET Blog

إعداد النوافذ العائمة في 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 قد أزعجتك يوماً، فاذهب وغيّر هذا الإعداد الآن.

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

Azure DevOps يُصلح أخيراً تجربة مستخدم محرر Markdown التي اشتكى منها الجميع

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

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

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

أعلن Dan Hellem عن هذا الإصلاح، وهو من التغييرات التي تبدو صغيرة لكنها تزيل احتكاكاً حقيقياً من سير عملك اليومي.

ما الذي تغيّر

يفتح محرر Markdown لحقول نص عناصر العمل الآن في وضع المعاينة افتراضياً. يمكنك قراءة المحتوى والتفاعل معه — اتباع الروابط ومراجعة التنسيق — دون القلق من الدخول إلى وضع التحرير عن طريق الخطأ.

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

هذا هو التغيير. هذا كل شيء.

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

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

بالنسبة للفرق التي تُجري تخطيط السبرينت، أو تنقية قائمة المهام المتراكمة، أو مراجعة الكود باستخدام Azure Boards، يتراكم هذا الاحتكاك الصغير. كل دخول غير مقصود إلى وضع التحرير يعني تحولاً في السياق. وكل لحظة “انتظر، هل غيّرت شيئاً؟” هي انتباه مُهدَر.

السلوك الافتراضي الجديد يحترم نمط التفاعل الأكثر شيوعاً: فأنت تقرأ عناصر العمل أكثر بكثير مما تحررها.

حالة الإطلاق

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

خلاصة القول

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

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 وجرّبه.

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.