Productivity | The .NET Blog

Visual Studio की वो Floating Windows सेटिंग जो आप नहीं जानते थे (लेकिन जाननी चाहिए)

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

अगर आप Visual Studio के साथ multiple monitors इस्तेमाल करते हैं (और सच कहें तो आजकल कौन नहीं करता), तो आपने यह परेशानी जरूर झेली होगी: floating tool windows मुख्य IDE minimize करते ही गायब हो जाती हैं, वे हमेशा बाकी सब चीज़ों के ऊपर रहती हैं, और taskbar में अलग बटन के रूप में नहीं दिखतीं। कुछ workflows के लिए यह ठीक है, लेकिन multi-monitor setups के लिए यह बहुत frustrating है।

Visual Studio टीम के Mads Kristensen ने एक कम-जानी-मानी सेटिंग share की जो floating windows के व्यवहार को पूरी तरह बदल देती है। बस एक dropdown। बस।

सेटिंग कहाँ है

Tools > Options > Environment > Windows > Floating Windows

“These floating windows are owned by the main window” dropdown में तीन विकल्प हैं:

None — पूरी स्वतंत्रता। हर floating window को अपना taskbar entry मिलता है और यह एक सामान्य Windows window की तरह व्यवहार करती है।
Tool Windows (default) — documents स्वतंत्र रूप से float होते हैं, tool windows IDE से जुड़ी रहती हैं।
Documents and Tool Windows — Visual Studio का classic व्यवहार, सब कुछ main window से बंधा रहता है।

Multi-monitor setups के लिए “None” ही सही विकल्प है

इसे None पर सेट करें और अचानक आपकी सभी floating tool windows और documents असली Windows applications की तरह व्यवहार करने लगती हैं। वे taskbar में दिखती हैं, main Visual Studio window minimize करने पर भी visible रहती हैं, और खुद को बाकी सब चीज़ों के आगे नहीं रखतीं।

इसे PowerToys FancyZones के साथ combine करें और यह game changer साबित होता है। अपने monitors पर custom layouts बनाएं, Solution Explorer को एक zone में snap करें, debugger को दूसरे में, और code files जहाँ चाहें। सब कुछ अपनी जगह रहता है, सब कुछ independently accessible है, और आपका workspace अव्यवस्थित की बजाय organised लगता है।

त्वरित सुझाव

Multi-monitor power users: None सेट करें, FancyZones के साथ जोड़ें
कभी-कभार float करने वाले: Tool Windows (default) एक अच्छा middle ground है
पारंपरिक workflow: Documents and Tool Windows सब कुछ classic रखता है

Pro tip: किसी भी tool window title bar पर Ctrl + double-click करके तुरंत float या dock करें। सेटिंग बदलने के बाद restart की जरूरत नहीं।

अंतिम बात

यह उन सेटिंग्स में से एक है जिनके बारे में सोचकर आप कहते हैं “मुझे यह पहले क्यों नहीं पता था”। अगर Visual Studio में floating windows ने कभी आपको परेशान किया है, तो अभी जाकर यह बदलें।

विवरण और screenshots के लिए पूरी पोस्ट पढ़ें।

Azure DevOps ने आखिरकार वो Markdown Editor UX ठीक किया जिसकी सबको शिकायत थी

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

अगर आप Azure Boards इस्तेमाल करते हैं, तो शायद आपने यह अनुभव किया होगा: आप किसी work item की description पढ़ रहे हैं, शायद acceptance criteria review कर रहे हैं, और गलती से double-click हो जाती है। बस — आप edit mode में चले जाते हैं। आप कुछ edit करना नहीं चाहते थे। आप बस पढ़ रहे थे।

Dan Hellem ने इस fix की घोषणा की, और यह उन बदलावों में से एक है जो सुनने में तो छोटा लगता है लेकिन वास्तव में आपकी रोज़ाना की workflow से असली परेशानी दूर करता है।

क्या बदला

work item text fields के लिए Markdown editor अब default रूप से preview mode में खुलता है। आप content पढ़ और उसके साथ इंटरैक्ट कर सकते हैं — links follow कर सकते हैं, formatting review कर सकते हैं — बिना गलती से edit mode में जाने की चिंता किए।

जब आप वास्तव में edit करना चाहते हैं, तो field के ऊपर edit icon पर क्लिक करें। जब काम हो जाए, तो explicitly preview mode पर वापस आ जाएं। सरल, जानबूझकर, और अनुमानित।

बस इतना ही। यही बदलाव है।

यह जितना लगता है उससे ज़्यादा मायने क्यों रखता है

इस पर community feedback thread काफी लंबा था। double-click-to-edit का behavior जुलाई 2025 में Markdown editor के साथ आया था, और शिकायतें लगभग तुरंत शुरू हो गईं। समस्या केवल गलत edits तक सीमित नहीं थी — पूरा interaction अप्रत्याशित लगता था। आपको कभी पता नहीं चलता था कि click करने से read होगा या edit।

जो teams Azure Boards के साथ sprint planning, backlog grooming, या code review करती हैं, उनके लिए इस तरह की micro-friction जमा होती रहती है। हर गलत edit mode entry एक context switch है। हर “रुको, क्या मैंने कुछ बदला?” वाला पल ध्यान की बर्बादी है।

नया default सबसे आम interaction pattern का सम्मान करता है: आप work items को edit करने से कहीं ज़्यादा बार पढ़ते हैं।

Rollout की स्थिति

यह पहले से ही कुछ customers के लिए rollout हो रहा है और अगले दो से तीन हफ्तों में सभी के लिए उपलब्ध हो जाएगा। अगर आपको अभी नहीं दिख रहा, तो जल्द ही दिखेगा।

निष्कर्ष

हर सुधार को headline feature नहीं होना चाहिए। कभी-कभी सबसे अच्छा update बस कुछ परेशान करने वाली चीज़ को हटाना होता है। यह उन्हीं में से एक है — एक छोटा UX fix जो Azure Boards को उन लोगों के लिए कम कठिन बनाता है जो बस शांति से अपने work items पढ़ना चाहते हैं।

Bookmark Studio, Visual Studio Bookmarks में Slot-Based Navigation और Sharing लाता है

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

Visual Studio में Bookmarks हमेशा से… ठीक-ठाक रही हैं। आप एक set करते हैं, अगले पर जाते हैं, और भूल जाते हैं कि कौन-सा bookmark किसके लिए था। वे काम करती हैं, लेकिन उन्हें कभी “शक्तिशाली” नहीं कहा जा सकता था।

Mads Kristensen ने हाल ही में Bookmark Studio release किया, एक experimental extension जो उन्हीं कमियों को भरता है जिनसे आप शायद तब परिचित हों जब bookmarks नियमित रूप से उपयोग करते हैं।

मुख्य नई सुविधा: bookmarks को अब slots 1–9 में assign किया जा सकता है और सीधे Alt+Shift+1 से Alt+Shift+9 के ज़रिए उन पर jump किया जा सकता है। नई bookmarks स्वचालित रूप से अगले उपलब्ध slot में चली जाती हैं, इसलिए ज़्यादातर मामलों में बिना किसी setup के तेज़ navigation काम करती है।

यह सरल लगता है, लेकिन इससे bookmarks “मेरे पास कुछ bookmarks हैं कहीं” से बदलकर “Slot 3 मेरा API controller है, Slot 5 service layer है, Slot 7 test है” हो जाती हैं। इस तरह की spatial memory, focused work sessions के दौरान navigation को लगभग तात्कालिक बना देती है।

Bookmark Manager

एक नया tool window सभी bookmarks को एक जगह दिखाता है जिसमें नाम, फ़ाइल, location, रंग या slot के अनुसार filtering होती है। किसी भी bookmark पर jump करने के लिए double-click करें या keyboard से navigate करें।

अगर आपके पास कभी पाँच-छह से अधिक bookmarks हों और आप ट्रैक न कर पाएँ कि कौन-सी किसके लिए थी, तो यह अकेले extension install करने के लिए पर्याप्त कारण है।

लेबल, रंग, और फ़ोल्डर के साथ organization

Bookmarks में वैकल्पिक रूप से लेबल, रंग हो सकते हैं और उन्हें फ़ोल्डर में group किया जा सकता है। इनमें से कुछ भी ज़रूरी नहीं है — आपका मौजूदा bookmark workflow काम करता रहेगा। लेकिन जब आप किसी जटिल समस्या को debug कर रहे हों या किसी अपरिचित codebase को explore कर रहे हों, तो bookmarks को color-code और label करने की क्षमता उपयोगी context जोड़ती है।

सभी metadata per solution store होता है, इसलिए आपकी bookmark organization sessions के पार बनी रहती है।

यह वह feature है जो मुझे पता नहीं था कि मुझे चाहिए था। Bookmark Studio आपको bookmarks को plain text, Markdown, या CSV के रूप में export करने देता है। इसका मतलब है कि आप:

Pull request descriptions में bookmark paths शामिल कर सकते हैं
Teammates के साथ investigation breadcrumbs share कर सकते हैं
Repos या branches के बीच bookmark sets move कर सकते हैं

Bookmarks अब केवल एक solo navigation tool नहीं रहतीं — ये “इस code से गुज़रने का रास्ता यहाँ है” communicate करने का ज़रिया बन जाती हैं।

Code Movement को Track करने वाली Bookmarks

Bookmark Studio, bookmarks को उस text के सापेक्ष track करता है जिससे वे anchored हैं, इसलिए edit करते समय वे गलत lines पर नहीं चली जातीं। अगर आपने कभी debugging session के दौरान bookmarks set की हों और refactor के बाद वे सब गलत lines पर point करने लगी हों — यह उसे ठीक करता है।

निष्कर्ष

Bookmark Studio कुछ नया नहीं करता। यह एक ऐसी feature को लेता है जो सालों से “काफी अच्छी” रही है और उसे focused development के लिए वास्तव में उपयोगी बनाता है। Slot navigation, Bookmark Manager, और export capabilities इसकी मुख्य विशेषताएँ हैं।

इसे Visual Studio Marketplace से प्राप्त करें और आज़माकर देखें।

VS Code 1.112: .NET डेवलपर्स के लिए वाकई जरूरी बातें

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

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

VS Code 1.112 आ गया है, और सच कहें तो? अगर आप अपने दिन .NET में बिता रहे हैं तो यह release अलग ही feel कराती है। official release notes में बहुत कुछ है, लेकिन मैं आपकी scrolling बचाता हूँ और focus करता हूँ उन चीज़ों पर जो हमारे लिए वाकई मायने रखती हैं।

Copilot CLI और भी उपयोगी हो गया

इस release का बड़ा theme है agent autonomy — Copilot को हर कदम पर निगरानी किए बिना काम करने की ज्यादा जगह देना।

Message steering और queueing

वह पल जब Copilot CLI किसी task के बीच में होता है और आपको याद आता है कि कुछ बताना भूल गए? पहले आपको इंतजार करना पड़ता था। अब आप request चलते हुए भी messages भेज सकते हैं — या तो current response को steer करने के लिए या follow-up instructions queue करने के लिए।

यह उन लंबे dotnet scaffolding tasks के लिए बहुत काम का है जहाँ आप Copilot को project setup करते देख रहे होते हैं और सोचते हैं “अरे रुको, मुझे MassTransit भी चाहिए था।”

Permission levels

यह वाला मुझे सबसे ज्यादा excited करता है। Copilot CLI sessions अब तीन permission levels support करती हैं:

Default Permissions — सामान्य flow जहाँ tools चलने से पहले confirmation माँगते हैं
Bypass Approvals — सब कुछ auto-approve करता है और errors पर retry करता है
Autopilot — पूरी तरह autonomous: tools approve करता है, अपने सवालों के खुद जवाब देता है, और task पूरा होने तक चलता रहता है

अगर आप एक नई ASP.NET Core API Entity Framework, migrations, और Docker setup के साथ scaffold कर रहे हैं — Autopilot mode का मतलब है कि आप बताएं क्या चाहिए और coffee लेने चले जाएं। यह खुद figure out कर लेगा।

Autopilot को chat.autopilot.enabled setting से enable कर सकते हैं।

Delegation से पहले changes preview करें

जब आप Copilot CLI को कोई task delegate करते हैं, तो यह एक worktree बनाता है। पहले, अगर आपके uncommitted changes थे, तो आपको Source Control में देखना पड़ता था। अब Chat view में decision लेने से पहले ही pending changes दिखते हैं — copy, move, या ignore करने के लिए।

छोटी बात है, लेकिन “रुको, मेरे पास क्या staged था?” वाला पल बचाती है।

VS Code से बाहर निकले बिना web apps debug करें

Integrated browser अब full debugging support करता है। आप breakpoints set कर सकते हैं, code step through कर सकते हैं, और variables inspect कर सकते हैं — सब VS Code के अंदर। Edge DevTools में switch करने की जरूरत नहीं।

एक नया editor-browser debug type है, और अगर आपके पास पहले से msedge या chrome launch configurations हैं, तो migrate करना उतना ही आसान है जितना launch.json में type field बदलना:

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

Blazor डेवलपर्स के लिए यह game changer है। आप terminal में dotnet watch पहले से चला रहे हैं — अब आपकी debugging भी उसी window में रहती है।

Browser को independent zoom levels भी मिले (आखिरकार), proper right-click context menus, और zoom हर website के लिए याद रखा जाता है।

MCP server sandboxing

यह आप जितना सोच रहे हैं उससे ज्यादा मायने रखता है। अगर आप MCP servers use कर रहे हैं — शायद आपने Azure resources या database queries के लिए custom बनाया है — तो वे आपके VS Code process जितनी ही permissions के साथ चल रहे थे। यानी आपके filesystem, network, सब कुछ तक पूरी access।

अब आप उन्हें sandbox कर सकते हैं। अपने mcp.json में:

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

जब किसी sandboxed server को कोई ऐसी चीज़ चाहिए जो उसके पास नहीं है, VS Code आपसे permission grant करने को कहता है। “उम्मीद है कोई कुछ अजीब नहीं करेगा” वाले तरीके से कहीं बेहतर।

नोट: Sandboxing अभी macOS और Linux पर उपलब्ध है। Windows support आ रहा है — WSL जैसे remote scenarios काम करते हैं।

Monorepo customizations discovery

अगर आप monorepo में काम कर रहे हैं (और सच कहें तो, कई enterprise .NET solutions आखिरकार एक बन जाते हैं), तो यह एक असली समस्या हल करता है।

पहले, अगर आप अपने repo का कोई subfolder खोलते थे, VS Code आपकी copilot-instructions.md, AGENTS.md, या custom skills जो repository root पर थीं, नहीं खोज पाता था। अब chat.useCustomizationsInParentRepositories setting के साथ, यह .git root तक जाकर सब कुछ खोजता है।

इसका मतलब है कि आपकी टीम monorepo के सभी projects में agent instructions, prompt files, और custom tools share कर सकती है, बिना सभी को root folder खोलने की जरूरत के।

Agent debugging के लिए /troubleshoot

कभी custom instructions या skills set up किए और सोचा क्यों pick up नहीं हो रहीं? नई /troubleshoot skill agent debug logs पढ़ती है और बताती है क्या हुआ — कौन से tools use हुए या skip हुए, instructions क्यों load नहीं हुए, और slow responses का कारण क्या है।

इसे enable करें:

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

फिर chat में बस /troubleshoot why is my custom skill not loading? type करें।

अब आप इन debug logs को export और import भी कर सकते हैं, जो तब बहुत काम आता है जब कुछ expected नहीं चल रहा हो और team के साथ share करना हो।

Image और binary file support

Agents अब disk से image files और binary files natively पढ़ सकते हैं। Binary files hexdump format में present होती हैं, और image outputs (जैसे integrated browser के screenshots) carousel view में दिखती हैं।

.NET डेवलपर्स के लिए सोचें: UI bug का screenshot chat में paste करें और agent समझे क्या गलत है, या Blazor component rendering का output analyze करवाएं।

Automatic symbol references

एक छोटा quality-of-life सुधार: जब आप किसी symbol का नाम (class, method, आदि) copy करके chat में paste करते हैं, VS Code अब automatically उसे #sym:Name reference में convert कर देता है। इससे agent को उस symbol का पूरा context मिल जाता है बिना आपको manually add किए।

अगर plain text चाहिए तो Ctrl+Shift+V use करें।

Plugins अब enable/disable हो सकते हैं

पहले, MCP server या plugin disable करने का मतलब था उसे uninstall करना। अब आप उन्हें on और off toggle कर सकते हैं — globally और per-workspace दोनों तरह से। Extensions view या Customizations view में right-click करें और काम हो गया।

npm और pypi के plugins अब auto-update भी हो सकते हैं, हालाँकि वे पहले approval माँगेंगे क्योंकि updates का मतलब है आपकी machine पर नया code चलाना।

अंतिम बात

VS Code 1.112 clearly agent experience पर जोर दे रहा है — अधिक autonomy, बेहतर debugging, tighter security। .NET डेवलपर्स के लिए, integrated browser debugging और Copilot CLI improvements standout features हैं।

अगर आपने अभी तक किसी .NET project के लिए Copilot CLI session Autopilot mode में नहीं चलाई है, तो यह release शुरू करने का अच्छा समय है। बस अपनी permissions set करें और इसे करने दें।

VS Code 1.112 download करें या VS Code के अंदर Help > Check for Updates से update करें।

Productivity | The .NET Blog

Visual Studio की वो Floating Windows सेटिंग जो आप नहीं जानते थे (लेकिन जाननी चाहिए)

सेटिंग कहाँ है

Multi-monitor setups के लिए “None” ही सही विकल्प है

त्वरित सुझाव

अंतिम बात

Azure DevOps ने आखिरकार वो Markdown Editor UX ठीक किया जिसकी सबको शिकायत थी

क्या बदला

यह जितना लगता है उससे ज़्यादा मायने क्यों रखता है

Rollout की स्थिति

निष्कर्ष

Bookmark Studio, Visual Studio Bookmarks में Slot-Based Navigation और Sharing लाता है

Slot-Based Navigation

Bookmark Manager

लेबल, रंग, और फ़ोल्डर के साथ organization

Export और Share

Code Movement को Track करने वाली Bookmarks

निष्कर्ष

VS Code 1.112: .NET डेवलपर्स के लिए वाकई जरूरी बातें

Copilot CLI और भी उपयोगी हो गया

Message steering और queueing

Permission levels

Delegation से पहले changes preview करें

VS Code से बाहर निकले बिना web apps debug करें

MCP server sandboxing

Monorepo customizations discovery

Agent debugging के लिए /troubleshoot

Image और binary file support

Automatic symbol references

Plugins अब enable/disable हो सकते हैं

अंतिम बात