Developer-Tools | The .NET Blog

Azure MCP Server अब .mcpb है — बिना किसी Runtime के इंस्टॉल करें

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

क्या आप जानते हैं MCP सर्वर सेटअप में क्या परेशान करता था? एक runtime की जरूरत थी। npm version के लिए Node.js, pip/uvx के लिए Python, dotnet variant के लिए .NET SDK।

Azure MCP Server ने अभी यह बदल दिया। यह अब .mcpb — एक MCP Bundle — के रूप में उपलब्ध है और सेटअप drag-and-drop है।

MCP Bundle क्या है?

इसे VS Code extension (.vsix) या browser extension (.crx) की तरह सोचें, लेकिन MCP servers के लिए। एक .mcpb फाइल एक self-contained ZIP archive है जिसमें server binary और सभी dependencies शामिल हैं।

कैसे इंस्टॉल करें

1. अपने प्लेटफॉर्म के लिए bundle डाउनलोड करें

GitHub Releases page पर जाएं और अपने OS और architecture के लिए .mcpb फाइल डाउनलोड करें।

2. Claude Desktop में इंस्टॉल करें

सबसे आसान तरीका: Extensions settings page (☰ → File → Settings → Extensions) खुलने पर .mcpb फाइल को Claude Desktop window में drag और drop करें। Server details review करें, Install पर क्लिक करें, confirm करें।

3. Azure में authenticate करें

az login

बस इतना। Azure MCP Server आपके मौजूदा Azure credentials का उपयोग करता है।

क्या कर सकते हैं

अपने AI client से सीधे 100+ Azure service tools तक पहुंच:

Cosmos DB, Storage, Key Vault, App Service, Foundry query और manage करें
किसी भी task के लिए az CLI commands generate करें
Bicep और Terraform templates बनाएं

शुरुआत करने के लिए

Download: GitHub Releases
Repo: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

पूरी पोस्ट देखें।

VS Code 1.118: Copilot CLI को सेशन नाम, मॉडल बैज और TypeScript 7.0 Nightly ऑप्ट-इन मिला

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Visual Studio Code 1.118 एक छोटा, केंद्रित रिलीज़ है — मुख्यतः Copilot CLI सुधार।

Copilot CLI: सेशन को असली नाम मिलते हैं

Copilot CLI SDK के सेशन टाइटल APIs अब सेशन नामों के स्रोत के रूप में उपयोग होते हैं। ऑटो-जेनरेटेड लेबल की बजाय SDK का असली नाम दिखता है।

कीबोर्ड शॉर्टकट से तेज़ सेशन स्विचिंग

Agents ऐप में अब Ctrl+1, Ctrl+2 आदि से सेशन जल्दी बदले जा सकते हैं।

चैट में मॉडल बैज

Copilot CLI की चैट पैनल में प्रतिक्रियाओं पर अब मॉडल बैज दिखता है।

Copilot CLI में ऑटो मॉडल सिलेक्शन

ऑटो मॉडल सिलेक्शन अब Copilot CLI एजेंट में भी काम करता है।

TypeScript 7.0 Nightly ऑप्ट-इन

VS Code सेटिंग्स से सीधे TypeScript 7.0 नाइटली टेस्ट करने का विकल्प मिलता है। TypeScript 7.0 एक बड़ा रिलीज़ है (बीटा कुछ दिन पहले आया)।

पूर्ण रिलीज़ नोट्स देखें।

Foundry Toolboxes: AI Agents के लिए एक Unified Endpoint

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

एक problem है जो boring लगती है जब तक खुद face न करो: organization multiple AI agents बना रही है, हर एक को tools चाहिए, और हर team scratch से configure कर रही है। Same web search integration, same Azure AI Search config, same GitHub MCP server connection — लेकिन अलग repository में, अलग team द्वारा, अलग credentials के साथ, और कोई shared governance नहीं।

Microsoft Foundry ने Toolboxes को Public Preview में launch किया, और यह उस problem का direct answer है।

Toolbox क्या है

Toolbox एक named, reusable bundle of tools है जो एक बार Foundry में define होता है और single MCP-compatible endpoint के through expose होता है। कोई भी agent runtime जो MCP बोलता है वो इसे consume कर सकता है — Foundry Agents में कोई lock-in नहीं।

Promise simple है: build once, consume anywhere। Tools define करो, authentication centrally configure करो (OAuth passthrough, Entra managed identity), endpoint publish करो। जिस agent को वो tools चाहिए वो endpoint से connect करे और सभी मिल जाएं।

चार pillars (आज दो available)

Pillar	Status	क्या करता है
Discover	Coming soon	Manual search बिना approved tools खोजना
Build	Available	Tools को reusable bundle में group करना
Consume	Available	Single MCP endpoint सभी tools expose करता है
Govern	Coming soon	Centralized auth + सभी tool calls की observability

Practical Example

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Documentation search करो और GitHub issues का जवाब दो",
 tools=[
 {"type": "web_search", "description": "Public documentation search"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Publish होने के बाद Foundry unified endpoint देता है। एक connection, सभी tools।

Foundry Agents में lock-in नहीं

Toolboxes Foundry में create और manage होते हैं, लेकिन consumption surface open MCP protocol है। Microsoft Agent Framework या LangGraph के custom agents, GitHub Copilot और अन्य MCP-enabled IDEs, कोई भी MCP-speaking runtime इन्हें use कर सकता है।

अभी क्यों important है

Multi-agent wave production में पहुंच रही है। हर नया agent duplicate configuration, stale credentials और inconsistent behavior की नई surface है। Build + Consume foundation centralization शुरू करने के लिए काफी है। जब Govern pillar आएगा, पूरी agent fleet के लिए fully observable, centrally controlled tool layer मिलेगी।

निष्कर्ष

यह अभी भी early है — Public Preview, Python SDK पहले, Discover और Govern अभी आने हैं। लेकिन model solid है और MCP-native design का मतलब है कि यह उन tools के साथ काम करता है जो already build हो रहे हैं। Official announcement देखें।

Python, TypeScript और .NET में azd Hooks: Shell Scripts से मुक्ति

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

अगर आपने कभी पूरी तरह .NET में बना प्रोजेक्ट रखा हो और फिर भी azd hooks के लिए Bash scripts लिखनी पड़ी हों, तो वो दर्द आप समझते हैं। जब प्रोजेक्ट का बाकी सब कुछ C# है, तो pre-provisioning step के लिए shell syntax में क्यों जाएं?

वो frustration अब officially solve हो गई है। Azure Developer CLI ने hooks के लिए multi-language support launch किया है, और यह उतना ही अच्छा है जितना सुनाई देता है।

Hooks क्या हैं

Hooks वो scripts हैं जो azd lifecycle के key points पर run होती हैं — provisioning से पहले, deployment के बाद, और अन्य। ये azure.yaml में define होती हैं और CLI को modify किए बिना custom logic inject करने देती हैं।

पहले सिर्फ Bash और PowerShell support थे। अब Python, JavaScript, TypeScript या .NET use कर सकते हैं — बाकी सब azd automatically handle करता है।

Detection कैसे काम करती है

बस hook को एक file पर point करें और azd extension से language infer करता है:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

कोई extra config नहीं। अगर extension ambiguous हो तो kind: python (या relevant language) explicitly specify कर सकते हैं।

Language-specific details

Python

Script के साथ (या किसी parent directory में) requirements.txt या pyproject.toml रखें। azd automatically virtual environment बनाएगा, dependencies install करेगा और script run करेगा।

JavaScript और TypeScript

Same pattern — script के पास package.json रखें और azd पहले npm install run करेगा। TypeScript के लिए npx tsx use होता है, बिना compile step और बिना tsconfig.json।

.NET

दो modes उपलब्ध:

Project mode: Script के पास .csproj हो तो azd automatically dotnet restore और dotnet build run करता है।
Single-file mode: .NET 10+ पर standalone .cs files सीधे dotnet run script.cs से run होती हैं। Project file की जरूरत नहीं।

Executor-specific configuration

हर language optional config block support करती है:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET developers के लिए क्यों मायने रखता है

Hooks azd-based project में वो आखिरी जगह थी जो language switch करने पर मजबूर करती थी। अब पूरा deployment pipeline — app code से लेकर lifecycle hooks तक — एक ही language में रह सकता है। Existing .NET utilities hooks में reuse कर सकते हैं, shared libraries reference कर सकते हैं, और shell script maintenance से छुटकारा मिलता है।

निष्कर्ष

ये उन changes में से एक है जो छोटे लगते हैं लेकिन azd के daily workflow से बहुत friction हटाते हैं। Hooks के लिए multi-language support अभी available है — full documentation के लिए official post देखें।

Windows App Dev CLI v0.3: टर्मिनल से F5 डीबग और एजेंट्स के लिए UI ऑटोमेशन

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

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

Visual Studio का F5 अनुभव शानदार है। लेकिन सिर्फ एक पैकेज्ड Windows ऐप को लॉन्च और डीबग करने के लिए VS खोलना — चाहे वो CI पाइपलाइन हो, ऑटोमेटेड वर्कफ्लो हो, या AI एजेंट टेस्ट चला रहा हो — बहुत ज्यादा है।

Windows App Development CLI v0.3 अभी लॉन्च हुई है और दो मुख्य फीचर्स के साथ इसका सीधा समाधान देती है: winapp run और winapp ui।

winapp run: कहीं से भी F5

winapp run एक अनपैकेज्ड ऐप फोल्डर और मैनिफेस्ट लेती है, और वो सब करती है जो VS डीबग लॉन्च में करता है: एक loose पैकेज रजिस्टर करना, ऐप लॉन्च करना और री-डिप्लॉय के बीच LocalState बनाए रखना।

# ऐप बिल्ड करें, फिर पैकेज्ड ऐप की तरह चलाएं
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia और अधिक के लिए काम करता है। मोड्स डेवलपर्स और ऑटोमेटेड वर्कफ्लो दोनों के लिए बनाए गए हैं:

--detach: लॉन्च के तुरंत बाद टर्मिनल को कंट्रोल वापस करता है। CI के लिए आदर्श।
--unregister-on-exit: ऐप बंद होने पर रजिस्टर्ड पैकेज हटाता है।
--debug-output: OutputDebugString संदेश और exceptions रियल-टाइम में कैप्चर करता है।

नया NuGet पैकेज: पैकेज्ड ऐप्स के लिए dotnet run

.NET डेवलपर्स के लिए एक नया NuGet पैकेज है: Microsoft.Windows.SDK.BuildTools.WinApp। इंस्टॉल के बाद dotnet run पूरा इनर लूप संभालता है: बिल्ड, loose-layout पैकेज तैयार करना, Windows में रजिस्टर करना और लॉन्च — सब एक स्टेप में।

winapp init
# या
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: कमांड लाइन से UI ऑटोमेशन

यह वो फीचर है जो एजेंटिक सीनेरियो खोलता है। winapp ui टर्मिनल से किसी भी चल रहे Windows ऐप (WPF, WinForms, Win32, Electron, WinUI3) तक पूर्ण UI Automation एक्सेस देता है।

क्या किया जा सकता है:

सभी टॉप-लेवल विंडो सूचीबद्ध करें
किसी भी विंडो के पूर्ण UI Automation ट्री को नेविगेट करें
नाम, टाइप या ऑटोमेशन ID से एलिमेंट खोजें
क्लिक, invoke और मान सेट करें
स्क्रीनशॉट लें
एलिमेंट दिखने का इंतजार करें — टेस्ट सिंक्रोनाइजेशन के लिए आदर्श

winapp ui और winapp run को मिलाकर टर्मिनल से पूरा build → लॉन्च → वेरिफाई वर्कफ्लो बनाया जा सकता है। एक एजेंट ऐप चला सकता है, UI स्थिति देख सकता है, प्रोग्रामेटिकली इंटरेक्ट कर सकता है और परिणाम validate कर सकता है।

अन्य नई सुविधाएं

winapp unregister: काम पूरा होने पर sideloaded पैकेज हटाएं।
winapp manifest add-alias: टर्मिनल से नाम से ऐप लॉन्च करने के लिए alias जोड़ें।
Tab completion: PowerShell के लिए एक कमांड से completion सेटअप करें।

कैसे प्राप्त करें

winget install Microsoft.WinAppCli
# या
npm install -g @microsoft/winappcli

CLI पब्लिक प्रीव्यू में है। पूरी डॉक्यूमेंटेशन के लिए GitHub रिपॉजिटरी देखें और सभी विवरण के लिए मूल घोषणा देखें।

VS Code 1.117: Agents को अपनी Git Branch मिल रही है — और मैं इसके साथ हूँ

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

“AI assistant” और “AI teammate” के बीच की रेखा लगातार पतली होती जा रही है। VS Code 1.117 अभी आया है और full release notes भरे पड़े हैं, लेकिन यहाँ की कहानी साफ है: agents आपके dev workflow में first-class citizens बनते जा रहे हैं।

यहाँ वो है जो वाकई मायने रखता है।

Autopilot mode आखिरकार आपकी preference याद रखता है

पहले, हर नई session शुरू करने पर Autopilot को फिर से enable करना पड़ता था। परेशान करने वाला। अब आपका permission mode sessions के पार persist होता है, और आप default configure कर सकते हैं।

Agent Host तीन session configs support करता है:

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

अगर आप migrations, Docker, और CI के साथ एक नया .NET project scaffold कर रहे हैं — एक बार Autopilot set करें और भूल जाएं। वह preference बनी रहती है।

Agent sessions के लिए Worktree और git isolation

यह बड़ी बात है। Agent sessions अब पूरी worktree और git isolation support करती हैं। इसका मतलब है जब कोई agent किसी task पर काम करता है, उसे अपनी branch और working directory मिलती है। आपकी main branch untouched रहती है।

इससे भी बेहतर — Copilot CLI इन worktree sessions के लिए meaningful branch names generate करता है। अब agent-session-abc123 नहीं। आपको कुछ ऐसा मिलता है जो वास्तव में बताता है agent क्या कर रहा है।

Multiple feature branches चलाने वाले या एक लंबे scaffolding task के दौरान bugs fix करने वाले .NET डेवलपर्स के लिए, यह game changer है। आपका एक agent एक worktree में API controllers बना सकता है जबकि आप दूसरे में service layer issue debug कर रहे हैं। कोई conflicts नहीं। कोई stashing नहीं। कोई mess नहीं।

Subagents और agent teams

Agent Host Protocol अब subagents support करता है। एक agent किसी task के हिस्सों को handle करने के लिए दूसरे agents spin up कर सकता है। इसे delegation की तरह सोचें — आपका main agent coordinate करता है, और specialized agents टुकड़े handle करते हैं।

यह early है, लेकिन .NET workflows के लिए potential स्पष्ट है। कल्पना करें एक agent आपके EF Core migrations handle करे जबकि दूसरा integration tests setup करे। हम पूरी तरह वहाँ नहीं हैं, लेकिन अभी protocol support land होने का मतलब है tooling जल्दी आएगी।

Agents input भेजने पर terminal output automatically include होता है

छोटा लेकिन meaningful। जब कोई agent terminal को input भेजता है, terminal output अब automatically context में include हो जाता है। पहले, agent को बस यह देखने के लिए एक extra turn लेना पड़ता था कि क्या हुआ।

अगर आपने कभी किसी agent को dotnet build चलाते, fail होते, और फिर error देखने के लिए सिर्फ एक और round-trip लेते देखा है — वह friction खत्म हो गया। यह output तुरंत देखता है और react करता है।

macOS पर self-updating Agents app

macOS पर standalone Agents app अब self-update करती है। अब manually नए versions download नहीं करने होंगे। यह बस current रहती है।

जानने लायक छोटी बातें

package.json hovers अब installed version और latest available दोनों दिखाते हैं। Useful है अगर आप .NET projects के साथ npm tooling manage करते हैं।
JSDoc comments में Images hovers और completions में सही render होती हैं।
Copilot CLI sessions अब indicate करती हैं कि वे VS Code द्वारा बनाई गईं या externally — handy जब आप terminals के बीच jump कर रहे हों।
Copilot CLI, Claude Code, और Gemini CLI shell types के रूप में recognize होते हैं। Editor जानता है आप क्या चला रहे हैं।

निष्कर्ष

VS Code 1.117 कोई flashy feature dump नहीं है। यह infrastructure है। Worktree isolation, persistent permissions, subagent protocols — ये उस workflow के building blocks हैं जहाँ agents बिना आपके code पर कदम रखे real, parallel tasks handle करते हैं।

अगर आप .NET से build कर रहे हैं और अभी तक agentic workflow में नहीं उतरे हैं, तो honestly, अब शुरू करने का समय है।

Docker Sandbox, Copilot Agents को आपकी मशीन को जोखिम में डाले बिना Code Refactor करने देता है

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

अगर आपने Copilot के agent mode का उपयोग छोटे edits से परे किसी काम के लिए किया है, तो आप वह तकलीफ जानते हैं। हर file write, हर terminal command — एक और permission prompt। अब कल्पना करें कि यह 50 projects में चलाना हो। मज़ेदार नहीं।

Azure team ने GitHub Copilot agents के लिए Docker Sandbox के बारे में एक post publish किया है, और सच में, यह सबसे practical agentic tooling improvements में से एक है जो मैंने देखी है। यह microVMs का उपयोग करता है ताकि Copilot को एक पूरी तरह से isolated environment मिल सके जहाँ यह खुलकर काम कर सके — packages install करना, builds चलाना, tests execute करना — आपके host system को छुए बिना।

Docker Sandbox वास्तव में क्या देता है

Core idea सरल है: एक पूर्ण Linux environment के साथ एक lightweight microVM spin up करें, अपना workspace उसमें sync करें, और Copilot agent को उसके अंदर freely काम करने दें। जब यह हो जाए, changes sync back हो जाती हैं।

यहाँ वह है जो इसे सिर्फ “container में चीज़ें चलाने” से अधिक बनाता है:

Bidirectional workspace sync जो absolute paths को preserve करता है। आपकी project structure sandbox के अंदर बिल्कुल एक जैसी दिखती है। Path-related build failures नहीं।
Private Docker daemon जो microVM के अंदर चलता है। Agent containers build और run कर सकता है बिना कभी आपके host के Docker socket को mount किए। Security के लिए यह बहुत बड़ी बात है।
HTTP/HTTPS filtering proxies जो control करते हैं कि agent network पर क्या reach कर सकता है। आप तय करते हैं कि कौन-से registries और endpoints allowed हैं। Sandbox के अंदर एक rogue npm install से supply chain attacks? Blocked।
YOLO mode — हाँ, यही वे इसे कहते हैं। Agent बिना permission prompts के चलता है क्योंकि यह literally आपके host को नुकसान नहीं पहुँचा सकता। हर destructive action contained है।

.NET Developers को क्यों परवाह करनी चाहिए

उस modernization work के बारे में सोचें जिसका सामना इतनी सारी teams कर रही हैं। आपके पास 30 projects का एक .NET Framework solution है, और आपको इसे .NET 9 पर move करना है। वह सैकड़ों file changes हैं — project files, namespace updates, API replacements, NuGet migrations।

Docker Sandbox के साथ, आप एक Copilot agent को किसी project पर point कर सकते हैं, उसे microVM के अंदर freely refactor करने दे सकते हैं, validate करने के लिए dotnet build और dotnet test चला सकते हैं, और केवल वे changes accept कर सकते हैं जो वास्तव में काम करती हैं। इस जोखिम के बिना कि experimenting करते समय यह आपके local dev environment को accidentally बर्बाद कर दे।

Post में parallel agents की एक fleet चलाने का भी वर्णन है — प्रत्येक अपने sandbox में — जो एक साथ अलग-अलग projects से निपटती हैं। बड़े .NET solutions या microservice architectures के लिए, यह बहुत बड़ा समय बचाने वाला है। एक agent per service, सभी isolated होकर चल रहे हैं, सभी independently validate हो रहे हैं।

Security पक्ष मायने रखता है

यहाँ वह बात है जो ज़्यादातर लोग छोड़ देते हैं: जब आप एक AI agent को arbitrary commands execute करने देते हैं, तो आप उस पर अपनी पूरी machine का भरोसा कर रहे हैं। Docker Sandbox उस model को पलट देता है। Agent को एक throwaway environment के अंदर पूरी autonomy मिलती है। Network proxy सुनिश्चित करता है कि यह केवल approved sources से pull कर सकता है। आपका host filesystem, Docker daemon, और credentials अछूते रहते हैं।

Compliance requirements वाली teams के लिए — और ज़्यादातर enterprise .NET shops की यही स्थिति है — यह “हम agentic AI उपयोग नहीं कर सकते” और “हम इसे safely adopt कर सकते हैं” के बीच का अंतर है।

निष्कर्ष

Docker Sandbox agentic coding के मूलभूत tension को हल करता है: agents को उपयोगी होने के लिए स्वतंत्रता चाहिए, लेकिन आपकी host machine पर स्वतंत्रता खतरनाक है। MicroVMs आपको दोनों देते हैं। अगर आप कोई बड़े पैमाने का .NET refactoring या modernization plan कर रहे हैं, तो इसे अभी set up करना उचित है। Copilot की code intelligence को एक safe execution environment के साथ मिलाना ठीक वही है जिसका production teams इंतज़ार कर रही थीं।

Terminal की देखभाल बंद करें: Aspire का Detached Mode Workflow बदल देता है

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

हर बार जब आप Aspire AppHost चलाते हैं, तो आपका terminal चला जाता है। बंद। कब्ज़ा हो जाता है जब तक आप Ctrl+C से बाहर नहीं निकलते। एक quick command चलानी है? दूसरा tab खोलिए। Logs चेक करने हैं? एक और tab। यह एक छोटी सी रुकावट है जो जल्दी बड़ी हो जाती है।

Aspire 13.2 इसे ठीक करता है। James Newton-King ने पूरी जानकारी लिखी है, और सच कहूँ तो, यह उन features में से एक है जो तुरंत आपके काम करने का तरीका बदल देती है।

Detached mode: एक command, terminal वापस

aspire start

यह aspire run --detach का shorthand है। आपका AppHost background में boot होता है और आपको तुरंत terminal वापस मिल जाता है। कोई extra tab नहीं। कोई terminal multiplexer नहीं। बस आपका prompt, काम के लिए तैयार।

जो चल रहा है उसे manage करना

यहाँ बात यह है — background में चलाना तभी उपयोगी है जब आप वाकई manage कर सकें कि क्या चल रहा है। Aspire 13.2 इसके लिए CLI commands का पूरा सेट लेकर आता है:

# सभी running AppHosts की list
aspire ps

# किसी specific AppHost की state देखें
aspire describe

# किसी running AppHost के logs stream करें
aspire logs

# किसी specific AppHost को रोकें
aspire stop

इससे Aspire CLI एक proper process manager बन जाता है। आप कई AppHosts शुरू कर सकते हैं, उनकी status चेक कर सकते हैं, उनके logs tail कर सकते हैं, और उन्हें बंद कर सकते हैं — सब एक ही terminal session से।

Isolated mode के साथ मिलाएं

Detached mode naturally isolated mode के साथ काम करता है। क्या आप बिना port conflicts के background में एक ही project के दो instances चलाना चाहते हैं?

aspire start --isolated
aspire start --isolated

हर एक को random ports, अलग secrets, और अपना lifecycle मिलता है। दोनों देखने के लिए aspire ps का उपयोग करें, जिसे बंद करना हो उसके लिए aspire stop का।

Coding agents के लिए यह क्यों बड़ी बात है

यहीं चीज़ें वाकई दिलचस्प हो जाती हैं। आपके terminal में काम करने वाला एक coding agent अब यह कर सकता है:

aspire start से app शुरू करें
aspire describe से उसकी state query करें
समस्याएं diagnose करने के लिए aspire logs से logs चेक करें
काम हो जाने पर aspire stop से बंद करें

बिना terminal session खोए। Detached mode से पहले, एक agent जो आपका AppHost चलाता वह अपने ही terminal से lock out हो जाता। अब वह शुरू कर सकता है, observe कर सकता है, iterate कर सकता है, और cleanup कर सकता है — बिल्कुल वैसे जैसा आप एक autonomous agent से चाहते हैं।

Aspire team ने इसी पर ध्यान दिया। aspire agent init चलाने से एक Aspire skill file setup होती है जो agents को ये commands सिखाती है। तो Copilot का coding agent जैसे tools out of the box ही आपके Aspire workloads manage कर सकते हैं।

निष्कर्ष

Detached mode एक simple flag के रूप में छुपा हुआ workflow upgrade है। आप terminals के बीच context-switch करना बंद कर देते हैं, agents खुद को block करना बंद कर देते हैं, और नए CLI commands आपको यह देखने की असली visibility देते हैं कि क्या चल रहा है। यह practical है, यह clean है, और यह daily development loop को ध्यान देने योग्य रूप से smooth बनाता है।

सभी details के लिए पूरा पोस्ट पढ़ें और aspire update --self से Aspire 13.2 प्राप्त करें।

Azure MCP Tools अब Visual Studio 2022 में बिल्ट-इन हैं — कोई Extension ज़रूरी नहीं

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

अगर आप Visual Studio में अलग extension के ज़रिए Azure MCP tools use करते रहे हैं, तो आप उस झंझट से परिचित हैं — VSIX install करो, restart करो, उम्मीद करो कि टूटे नहीं, version mismatches manage करो। वो friction अब खत्म हो गई।

Yun Jung Choi ने घोषणा की कि Azure MCP tools अब सीधे Visual Studio 2022 में Azure development workload के हिस्से के रूप में आते हैं। कोई extension नहीं। कोई VSIX नहीं। कोई restart dance नहीं।

इसका वास्तव में क्या मतलब है

Visual Studio 2022 version 17.14.30 से शुरू होकर, Azure MCP Server Azure development workload के साथ bundled आता है। अगर आपके पास पहले से वो workload installed है, तो बस GitHub Copilot Chat में उसे toggle on करना है और आप तैयार हैं।

45 Azure services में 230 से अधिक tools — सीधे chat window से accessible। अपने storage accounts list करें, ASP.NET Core app deploy करें, App Service issues diagnose करें, Log Analytics query करें — बिना browser tab खोले।

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

Developer tooling की असली बात यह है: हर extra step friction है, और friction adoption को मार देती है। MCP को एक अलग extension के रूप में रखने का मतलब था version mismatches, installation failures, और एक और चीज़ जो update रखनी होगी। इसे workload में बेक करने का मतलब है:

Visual Studio Installer के ज़रिए एकल update path
Extension और IDE के बीच कोई version drift नहीं
हमेशा current — MCP Server VS के regular releases के साथ update होता है

Azure पर standardize करने वाली teams के लिए यह बड़ी बात है। Workload एक बार install करें, tools enable करें, और वे हर session के लिए वहाँ मौजूद हैं।

इससे आप क्या कर सकते हैं

Tools Copilot Chat के ज़रिए पूरे development lifecycle को cover करते हैं:

सीखें — Azure services, best practices, architecture patterns के बारे में पूछें
Design और develop करें — service recommendations पाएं, app code configure करें
Deploy करें — resources provision करें और IDE से सीधे deploy करें
Troubleshoot करें — logs query करें, resource health check करें, production issues diagnose करें

एक quick example — Copilot Chat में यह type करें:

List my storage accounts in my current subscription.

Copilot पर्दे के पीछे Azure MCP tools call करता है, आपके subscriptions query करता है, और names, locations, और SKUs के साथ एक formatted list return करता है। कोई portal ज़रूरी नहीं।

इसे कैसे enable करें

Visual Studio 2022 17.14.30 या उससे ऊपर update करें
सुनिश्चित करें कि Azure development workload installed है
GitHub Copilot Chat खोलें
Select tools button (दो wrenches icon) पर क्लिक करें
Azure MCP Server को toggle on करें

बस इतना। यह sessions के बीच enabled रहता है।

एक ध्यान देने योग्य बात

Tools default रूप से disabled हैं — आपको opt in करना होगा। VS 2026-specific tools VS 2022 में उपलब्ध नहीं हैं। Tool availability आपके Azure subscription permissions पर भी निर्भर करती है, जैसे portal में होती है।

बड़ी तस्वीर

यह एक स्पष्ट trend का हिस्सा है: MCP developer IDEs में cloud tools surface करने का मानक तरीका बनता जा रहा है। हम पहले ही Azure MCP Server 2.0 stable release और VS Code तथा अन्य editors में MCP integrations देख चुके हैं। इसे Visual Studio के workload system में built in होना स्वाभाविक प्रगति है।

हम .NET developers जो Visual Studio में काम करते हैं, उनके लिए यह Azure portal पर context-switch करने का एक और कारण हटाता है। और सच में, जितना कम tab-switching, उतना बेहतर।

azd update — आपके सभी Package Managers को एक Command से संभालें

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

आपने वो “azd का नया version उपलब्ध है” message ज़रूर देखा होगा जो हर कुछ हफ्तों में pop up होता है? वो जिसे आप dismiss कर देते हैं क्योंकि आपको याद नहीं कि आपने azd winget से install किया था, Homebrew से, या उस curl script से जो आपने छह महीने पहले चलाई थी? हाँ, यह finally ठीक हो गया।

Microsoft ने azd update ship किया है — एक single command जो Azure Developer CLI को latest version में update करती है चाहे आपने इसे originally कैसे भी install किया हो। Windows, macOS, Linux — कोई फर्क नहीं। एक command।

यह कैसे काम करता है

azd update

बस इतना ही। अगर आप नए features का early access चाहते हैं, तो आप daily insiders build पर switch कर सकते हैं:

azd update --channel daily
azd update --channel stable

Command आपकी current installation method detect करती है और under the hood appropriate update mechanism use करती है। अब “रुको, इस machine पर मैंने winget use किया था या choco?” नहीं।

छोटी सी catch

azd update version 1.23.x से शुरू होकर ship होती है। अगर आप पुराने version पर हैं, तो आपको अपनी original installation method से एक आखिरी manual update करनी होगी। उसके बाद, azd update सब कुछ forward में handle करेगा।

azd version से अपना current version check करें। अगर आपको fresh install की ज़रूरत है, install docs में सब है।

यह क्यों मायने रखता है

यह एक छोटा quality-of-life improvement है, लेकिन उन लोगों के लिए जो daily basis पर Azure पर AI agents और Aspire apps deploy करने के लिए azd use करते हैं, current रहने का मतलब है कम “यह bug तो latest version में already fix हो गया था” moments। एक कम चीज़ जिसके बारे में सोचना पड़े।

अधिक context के लिए पूरी announcement और Jon Gallant का deeper dive पढ़ें।

.NET Aspire 13.2 आपके AI Agent का सबसे अच्छा दोस्त बनना चाहता है

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

क्या आप जानते हैं वह moment जब आपका AI coding agent कुछ solid code लिखता है, आप excited हो जाते हैं, और फिर वह चीज़ चलाने की कोशिश में सब बिखर जाता है? Port conflicts, phantom processes, गलत environment variables — अचानक आपका agent features बनाने की जगह startup issues troubleshoot करने में tokens जला रहा है।

Aspire team ने एक thoughtful post छोड़ी है इसी problem के बारे में, और उनका जवाब compelling है: Aspire 13.2 सिर्फ humans के लिए नहीं, बल्कि AI agents के लिए भी design किया गया है।

Aspire as agent infrastructure

यहाँ है Aspire 13.2 agentic development के लिए क्या लाता है:

Typed code में पूरा stack। AppHost पूरी topology define करता है — compilable TypeScript या C# में:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

एक command सब कुछ के लिए। docker compose up, npm run dev, और database startup scripts juggle करने के बजाय, सब कुछ बस aspire start है।

Parallel agents के लिए isolated mode। --isolated के साथ, हर Aspire run को अपने random ports और separate user secrets मिलते हैं।

Telemetry के माध्यम से agent की नज़र। Aspire CLI development के दौरान full OpenTelemetry data expose करता है — traces, metrics, structured logs।

Bowling bumper analogy

Aspire team एक बढ़िया analogy उपयोग करती है: Aspire को AI agents के लिए bowling lane bumpers के रूप में सोचें। अगर agent perfect नहीं है, तो bumpers उसे gutter balls फेंकने से रोकते हैं।

शुरुआत करना

Aspire में नए हैं? get.aspire.dev से CLI install करें। पहले से Aspire use कर रहे हैं? aspire update --self चलाएं। पूरी post पढ़ें।

Aspire का Isolated Mode Parallel Development के लिए Port Conflict के nightmare को ठीक करता है

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

अगर आपने कभी एक ही project के दो instances एक साथ चलाने की कोशिश की है, तो आप इस दर्द को जानते हैं। Port 8080 already in use है। Port 17370 लिया हुआ है। कुछ terminate करो, restart करो, environment variables juggle करो — यह productivity killer है।

यह समस्या बेहतर नहीं हो रही, बल्कि बदतर हो रही है। AI agents independently काम करने के लिए git worktrees बनाते हैं। Background agents अलग environments spin up करते हैं। Developers feature branches के लिए एक ही repo को दो बार checkout करते हैं। इन सभी scenarios में एक ही दीवार आती है: एक ही app के दो instances एक ही ports पर लड़ रहे हैं।

Aspire 13.2 इसे एक single flag से ठीक करता है। Aspire team के James Newton-King ने पूरी जानकारी लिखी है, और यह उन features में से एक है जिसके बारे में आप सोचते हैं “यह पहले क्यों नहीं था”।

Fix: `--isolated`

aspire run --isolated

बस इतना ही। हर run को मिलता है:

Random ports — instances के बीच कोई collision नहीं
Isolated user secrets — connection strings और API keys हर instance के लिए अलग रहते हैं

कोई manual port reassignment नहीं। कोई environment variable juggling नहीं। हर run को automatically एक fresh, collision-free environment मिलता है।

Real scenarios जहाँ यह चमकता है

Multiple checkouts। एक directory में feature branch है और दूसरे में bugfix:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

दोनों बिना conflicts के चलते हैं। Dashboard दिखाता है कि क्या चल रहा है और कहाँ।

VS Code में background agents। जब Copilot Chat का background agent आपके code पर independently काम करने के लिए एक git worktree बनाता है, तो उसे आपका Aspire AppHost चलाना पड़ सकता है। --isolated के बिना, यह आपके primary worktree के साथ port collision है। इसके साथ, दोनों instances बस काम करते हैं।

aspire agent init के साथ ship होने वाली Aspire skill automatically agents को worktrees में काम करते समय --isolated use करने का निर्देश देती है। तो Copilot का background agent इसे out of the box handle करना चाहिए।

Development के साथ-साथ integration tests। Features build करते हुए एक live AppHost के against tests चलाने की ज़रूरत है? Isolated mode हर context को अपने ports और config देता है।

यह under the hood कैसे काम करता है

जब आप --isolated pass करते हैं, तो CLI run के लिए एक unique instance ID generate करता है। यह दो behaviors drive करता है:

Port randomization — आपके AppHost config में defined predictable ports को bind करने की बजाय, isolated mode सब कुछ के लिए random available ports pick करता है — dashboard, service endpoints, सब कुछ। Service discovery automatically adjust होती है, इसलिए services एक-दूसरे को ढूंढ लेती हैं चाहे वे किसी भी port पर land करें।
Secret isolation — हर isolated run को अपना user secrets store मिलता है, instance ID से keyed। एक run के connection strings और API keys दूसरे में leak नहीं होते।

आपके code में कोई बदलाव नहीं चाहिए। Aspire की service discovery endpoints को runtime पर resolve करती है, इसलिए सब कुछ सही से connect होता है चाहे port assignment कुछ भी हो।

इसे कब use करें

--isolated तब use करें जब एक ही AppHost के कई instances एक साथ चला रहे हों — चाहे वह parallel development हो, automated tests हों, AI agents हों, या git worktrees हों। Single-instance development के लिए जहाँ आप predictable ports पसंद करते हैं, regular aspire run अभी भी ठीक काम करता है।

निष्कर्ष

Isolated mode एक छोटी feature है जो एक असली, तेज़ी से common होती समस्या को हल करती है। जैसे-जैसे AI-assisted development हमें अधिक parallel workflows की तरफ धकेलता है — multiple agents, multiple worktrees, multiple contexts — ports पर लड़ाई के बिना बस एक और instance spin up करने की क्षमता ज़रूरी है।

सभी technical details के लिए पूरा पोस्ट पढ़ें और 13.2 आज़माने के लिए aspire update --self से update करें।

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 के लिए पूरी पोस्ट पढ़ें।

VS Code 1.116 — Agents App में Keyboard Navigation और File Context Completions

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

VS Code 1.116 April 2026 release है, और हालाँकि यह कुछ recent updates से हल्की है, बदलाव focused और meaningful हैं — खासकर अगर आप रोज़ाना Agents app use कर रहे हैं।

official release notes के आधार पर, यहाँ क्या मिला है।

Agents app में सुधार

Agents app उपयोगिता polish के साथ mature होता जा रहा है जो रोज़मर्रा के workflows में वास्तविक फर्क डालती है:

Dedicated keybindings — अब आप dedicated commands और keyboard shortcuts से Changes view, Changes के अंदर files tree, और Chat Customizations view focus कर सकते हैं। अगर आप Agents app में navigate करने के लिए click करते रहे हैं, तो यह पूरी keyboard-driven workflows लाता है।

Accessibility help dialog — chat input box में Alt+F1 दबाने पर अब एक accessibility help dialog खुलता है जो available commands और keybindings दिखाता है। Screen reader users announcement verbosity भी control कर सकते हैं। अच्छी accessibility सभी को फायदा पहुँचाती है।

File-context completions — Agents app chat में # type करें और आपके current workspace तक scoped file-context completions trigger होती हैं। यह उन छोटे quality-of-life improvements में से एक है जो हर interaction को तेज़ बनाती है — code reference करते समय अब पूरे file paths type नहीं करने होंगे।

CSS `@import` link resolution

Frontend developers के लिए एक अच्छी addition: VS Code अब CSS @import references resolve करता है जो node_modules paths use करते हैं। आप bundlers use करते समय @import "some-module/style.css" जैसे imports को Ctrl+click से follow कर सकते हैं। छोटा है लेकिन CSS workflows में एक friction point खत्म करता है।

अंतिम बात

VS Code 1.116 refinement के बारे में है — Agents app को अधिक navigable, अधिक accessible, और अधिक keyboard-friendly बनाना। अगर आप Agents app में काफी समय बिता रहे हैं (और मुझे लगता है हम में से कई बिता रहे हैं), तो ये बदलाव जुड़ते जाते हैं।

पूरी list के लिए full release notes देखें।

VS Code 1.115 — Background Terminal Notifications, SSH Agent Mode, और भी बहुत कुछ

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 अभी आया है, और हालाँकि headline features के मामले में यह थोड़ी हल्की release है, agent-related सुधार genuinely useful हैं अगर आप रोज़ाना AI coding assistants के साथ काम करते हैं।

आइए वो बातें highlight करें जो वाकई जानने लायक हैं।

Background terminals agents को जवाब देते हैं

यह standout feature है। Background terminals अब automatically agents को notify करते हैं जब commands पूरी होती हैं, जिसमें exit code और terminal output शामिल होता है। Background terminals में input prompts भी detect होते हैं और user को दिखाए जाते हैं।

यह क्यों मायने रखता है? अगर आपने background में build commands या test suites चलाने के लिए Copilot के agent mode का उपयोग किया है, तो आप जानते हैं “क्या वो खत्म हुई?” वाली परेशानी — background terminals essentially fire-and-forget थे। अब agent notify होता है जब आपका dotnet build या dotnet test पूरा होता है, output देखता है, और उसी के अनुसार react करता है। यह एक छोटा बदलाव है जो agent-driven workflows को काफी ज्यादा reliable बनाता है।

एक नया send_to_terminal tool भी है जो agents को user confirmation के साथ background terminals में commands भेजने देता है, उस समस्या को fix करते हुए जहाँ timeout के साथ run_in_terminal terminals को background में move कर देता था और उन्हें read-only बना देता था।

SSH remote agent hosting

VS Code अब SSH के ज़रिए remote machines से connect करने, CLI automatically install करने, और उसे agent host mode में start करने को support करता है। इसका मतलब है आपके AI agent sessions सीधे remote environments को target कर सकते हैं — .NET डेवलपर्स के लिए useful जो Linux servers या cloud VMs पर build और test करते हैं।

Agent sessions में edit tracking

Agent sessions के दौरान किए गए file edits अब track और restore होते हैं, diffs, undo/redo, और state restoration के साथ। अगर कोई agent आपके code में changes करता है और कुछ गलत हो जाता है, तो आप देख सकते हैं क्या बदला और उसे वापस ला सकते हैं। Agents को आपका codebase modify करने देने में मन की शांति।

Browser tab awareness और अन्य सुधार

कुछ और quality-of-life additions:

Browser tab tracking — chat अब session के दौरान खोले गए browser tabs को track और link कर सकती है, ताकि agents आपके देख रहे web pages reference कर सकें
Terminal में file paste — files (images सहित) Ctrl+V, drag-and-drop, या right-click से terminal में paste करें
Minimap में test coverage — quick visual overview के लिए test coverage indicators अब minimap में दिखते हैं
Mac पर pinch-to-zoom — integrated browser pinch-to-zoom gestures support करता है
Sessions में Copilot entitlements — status bar Sessions view में usage info दिखाता है
Go to File में Favicon — quick pick list में open web pages favicons दिखाते हैं

अंतिम बात

VS Code 1.115 एक incremental release है, लेकिन agent improvements — background terminal notifications, SSH agent hosting, और edit tracking — AI-assisted development के लिए noticeably smoother experience बनाते हैं। अगर आप .NET projects के लिए Copilot के agent mode का उपयोग कर रहे हैं, तो ये वो quality-of-life fixes हैं जो रोज़ाना friction कम करते हैं।

हर detail के लिए full release notes देखें।

Aspire 13.2 एक Docs CLI लेकर आया है — और आपका AI Agent भी इसका उपयोग कर सकता है

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

आपने वो पल ज़रूर महसूस किया होगा जब आप किसी Aspire AppHost में गहरे डूबे हों, integrations wire up कर रहे हों, और आपको ठीक-ठीक जाँचना हो कि Redis integration किन parameters की उम्मीद करती है। आप browser पर alt-tab करते हैं, aspire.dev पर खोजते हैं, API docs को ध्यान से देखते हैं, फिर editor पर वापस आते हैं। Context खो गया। Flow टूट गया।

Aspire 13.2 ने इसका हल ship किया है। aspire docs CLI आपको official Aspire documentation को सीधे अपने terminal से search, browse, और पढ़ने देता है। और चूंकि यह reusable services से backed है, AI agents और skills वही commands use करके docs lookup कर सकते हैं, न कि ऐसी APIs hallucinate करें जो exist ही नहीं करतीं।

यह वास्तव में किस समस्या को हल करता है

David Pine original post में बिल्कुल सही बात कहते हैं: AI agents Aspire apps बनाने में developers की मदद करने में बेकार थे। वे aspire run की जगह dotnet run recommend करते, aspire.dev के docs के लिए learn.microsoft.com reference करते, outdated NuGet packages suggest करते, और — मेरी personal favorite — ऐसी APIs hallucinate करते जो exist ही नहीं करतीं।

क्यों? क्योंकि Aspire polyglot बनने से कहीं ज़्यादा समय तक .NET-specific था, और LLMs ऐसे training data से काम कर रहे हैं जो latest features से पहले का है। जब आप एक AI agent को actual docs lookup करने की क्षमता देते हैं, तो वह अंदाज़े लगाना बंद कर देता है और उपयोगी बनने लगता है।

तीन commands, शून्य browser tabs

CLI refreshingly simple है:

सभी docs list करें

aspire docs list

aspire.dev पर available हर documentation page return करता है। Machine-readable output चाहिए? --format Json जोड़ें।

किसी topic को search करें

aspire docs search "redis"

weighted relevance scoring के साथ titles और content दोनों में search करता है। वही search engine जो internally documentation tooling को power करता है। आपको titles, slugs, और relevance scores के साथ ranked results मिलते हैं।

पूरा page पढ़ें (या सिर्फ एक section)

aspire docs get redis-integration

पूरा page markdown के रूप में आपके terminal में stream करता है। सिर्फ एक section चाहिए?

aspire docs get redis-integration --section "Add Redis resource"

सटीक precision। 500 lines scroll करने की ज़रूरत नहीं। बस वो हिस्सा जो आपको चाहिए।

AI agent का angle

यहाँ AI tooling के साथ build करने वाले developers के लिए दिलचस्प बात है। वही aspire docs commands AI agents के लिए tools की तरह काम करते हैं — skills, MCP servers, या simple CLI wrappers के ज़रिये।

आपके AI assistant के stale training data के आधार पर Aspire APIs बनाने की बजाय, वह aspire docs search "postgres" call कर सकता है, official integration docs ढूंढ सकता है, सही page पढ़ सकता है, और आपको documented approach दे सकता है। Real-time, current documentation — model ने छह महीने पहले जो memorize किया था वह नहीं।

इसके पीछे का architecture जानबूझकर बनाया गया है। Aspire team ने एक one-off integration की बजाय reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) बनाई हैं। इसका मतलब है कि वही search engine terminal में इंसानों के लिए, आपके editor में AI agents के लिए, और आपके CI pipeline में automation के लिए काम करता है।

Real-world scenarios

Quick terminal lookups: आप तीन files गहरे हैं और Redis config parameters चाहिए। दो commands, नब्बे सेकंड, काम पर वापस:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI-assisted development: आपकी VS Code skill CLI commands को wrap करती है। आप पूछते हैं “Add a PostgreSQL database to my AppHost” और agent जवाब देने से पहले actual docs lookup करता है। कोई hallucinations नहीं।

CI/CD validation: आपकी pipeline AppHost configurations को programmatically official documentation के against validate करती है। --format Json output jq और अन्य tools में cleanly pipe होता है।

Custom knowledge bases: अपना AI tooling बना रहे हैं? Structured JSON output को directly अपने knowledge base में pipe करें:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

कोई web scraping नहीं। कोई API keys नहीं। वही structured data जो docs tooling internally use करती है।

Documentation हमेशा live है

यही वह हिस्सा है जो मुझे सबसे ज़्यादा पसंद है। CLI एक snapshot download नहीं करता — यह ETag-based caching के साथ aspire.dev query करता है। जिस moment docs update होते हैं, आपका CLI और उस पर बना कोई भी skill उसे reflect करता है। कोई stale copies नहीं, कोई “but the wiki said…” moments नहीं।

निष्कर्ष

aspire docs उन छोटी features में से एक है जो एक असली समस्या को cleanly हल करती है। इंसानों को terminal-native documentation access मिलती है। AI agents को अंदाज़े लगाना बंद करके actual docs reference करने का तरीका मिलता है। और यह सब एक ही source of truth से backed है।

अगर आप .NET Aspire के साथ build कर रहे हैं और अभी तक CLI try नहीं किया है, तो aspire docs search "your-topic-here" चलाएं और देखें कैसा लगता है। फिर उन commands को जो भी AI skill या automation setup आप use कर रहे हैं उसमें wrap करने पर विचार करें — आपके agents आपको धन्यवाद देंगे।

David Pine का deep dive देखें कि docs tooling कैसे बनी, और सभी details के लिए official CLI reference।

azd अब आपको AI Agents को Locally Run और Debug करने देता है — March 2026 में क्या बदला

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

एक महीने में सात releases। यही Azure Developer CLI (azd) team ने March 2026 में deliver किया, और headline feature वही है जिसका मुझे इंतज़ार था: AI agents के लिए local run-and-debug loop।

PC Chan ने पूरा roundup publish किया है, और हालाँकि उसमें काफी कुछ है, लेकिन मुझे जो AI-powered apps build करने वाले .NET developers के लिए वाकई मायने रखता है वह filter करने दें।

Deploy किए बिना AI agents run और debug करें

यही बड़ी बात है। नया azure.ai.agents extension commands का एक set add करता है जो AI agents के लिए एक proper inner-loop experience देता है:

azd ai agent run — आपके agent को locally start करता है
azd ai agent invoke — उसे messages भेजता है (local या deployed)
azd ai agent show — container status और health display करता है
azd ai agent monitor — real time में container logs stream करता है

इससे पहले, एक AI agent को test करने का मतलब था हर बदलाव के बाद Microsoft Foundry में deploy करना। अब आप locally iterate कर सकते हैं, अपने agent के behavior को test कर सकते हैं, और deploy तभी करें जब आप ready हों। अगर आप Microsoft Agent Framework या Semantic Kernel के साथ agents build कर रहे हैं, तो यह आपके daily workflow को बदल देता है।

Invoke command local और deployed दोनों agents के against काम करता है, जिसका मतलब है कि आप same testing workflow use कर सकते हैं चाहे agent कहीं भी run हो। यह वह detail है जो आपको दो sets of test scripts maintain करने से बचाती है।

GitHub Copilot आपका azd project scaffold करता है

azd init अब “Set up with GitHub Copilot (Preview)” option offer करता है। अपने project structure के बारे में manually prompts का जवाब देने की बजाय, एक Copilot agent आपके लिए configuration scaffold करता है। यह कुछ modify करने से पहले dirty working directory check करता है और upfront MCP server tool consent माँगता है।

जब कोई command fail होती है, azd अब AI-assisted troubleshooting offer करता है: एक category चुनें (explain, guidance, troubleshoot, या skip), agent को fix suggest करने दें, और retry करें — terminal छोड़े बिना। Complex infrastructure setups के लिए, यह वाकई time saver है।

Container App Jobs और deployment improvements

कुछ deployment features जो ध्यान देने योग्य हैं:

Container App Jobs: azd अब existing host: containerapp config के ज़रिये Microsoft.App/jobs deploy करता है। आपका Bicep template decide करता है कि target Container App है या Job — कोई extra setup नहीं।
Configurable deployment timeouts: azd deploy पर नया --timeout flag और azure.yaml में deployTimeout field। Default 1200-second limit का अंदाज़ा लगाना अब नहीं।
Remote build fallback: जब remote ACR build fail हो, azd automatically local Docker/Podman build पर fallback करता है।
Local preflight validation: Bicep parameters Azure को round-trip किए बिना locally validate होते हैं, missing params पहले ही पकड़े जाते हैं।

Developer experience की polish

कुछ smaller improvements जो मिलकर फर्क डालती हैं:

JS/TS projects के लिए Automatic pnpm/yarn detection
Python packaging के लिए pyproject.toml support
Local template directories — azd init --template अब offline iteration के लिए filesystem paths accept करता है
--no-prompt mode में बेहतर error messages — सभी missing values एक साथ resolution commands के साथ report होते हैं
सभी framework build subprocesses (.NET, Node.js, Java, Python) में Build environment variables inject होते हैं

वह आखिरी बात subtle लेकिन महत्वपूर्ण है: आपके .NET build को अब azd environment variables का access है, जिसका मतलब है कि आप extra scripting के बिना build-time configuration injection कर सकते हैं।

निष्कर्ष

Local AI agent debugging loop इस release का star है, लेकिन deployment improvements और DX polish का जमावड़ा azd को पहले से कहीं ज़्यादा mature feel कराता है। अगर आप Azure पर .NET apps deploy कर रहे हैं — खासकर AI agents — तो यह update install करने लायक है।

हर detail के लिए पूरे release notes देखें, या azd install से शुरू करें।

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 से प्राप्त करें और आज़माकर देखें।

Visual Studio के March अपडेट में Custom Copilot Agents बनाने की सुविधा — और find_symbol टूल एक बड़ी बात है

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

Visual Studio को अब तक का सबसे महत्वपूर्ण Copilot अपडेट मिला है। Mark Downie ने March release की घोषणा की, और headline custom agents की है — लेकिन सच कहें तो थोड़ा आगे छुपा find_symbol टूल वह feature हो सकता है जो आपके workflow को सबसे ज्यादा बदलेगा।

आइए देखें यहाँ वास्तव में क्या है।

आपके repo में Custom Copilot agents

चाहते हैं कि Copilot आपकी टीम के coding standards का पालन करे, आपका build pipeline चलाए, या आपके internal docs query करे? अब आप ठीक वैसा ही बना सकते हैं।

Custom agents को .agent.md files के रूप में परिभाषित किया जाता है जिन्हें आप अपने repository में .github/agents/ में रखते हैं। प्रत्येक agent को workspace awareness, code understanding, tools, आपका preferred model, और external services से MCP connections तक पूरी access मिलती है। वे built-in agents के साथ agent picker में दिखते हैं।

यह वही pattern है जो VS Code support करता रहा है — और यह देखकर अच्छा लगता है कि Visual Studio भी catch up कर रहा है। जिन टीमों ने VS Code के लिए agents बनाए हैं, उनकी .agent.md files दोनों IDEs में काम करनी चाहिए (हालाँकि tool names भिन्न हो सकते हैं, इसलिए test करें)।

awesome-copilot repo में community-contributed agent configurations हैं जिन्हें आप starting points के रूप में use कर सकते हैं।

Agent skills: reusable instruction packs

Skills आपके repo में .github/skills/ या आपके profile में ~/.copilot/skills/ से automatically pick up होती हैं। प्रत्येक skill एक SKILL.md file है जो Agent Skills specification का पालन करती है।

Skills को modular expertise के रूप में सोचें जिन्हें आप mix और match कर सकते हैं। आपके पास आपके API conventions के लिए एक skill हो सकती है, testing patterns के लिए एक और, और deployment workflow के लिए एक अलग। जब कोई skill activate होती है, तो वह chat में दिखती है ताकि आप जान सकें कि वह apply हो रही है।

अगर आप VS Code में skills use कर रहे थे, तो अब वे Visual Studio में भी उसी तरह काम करती हैं।

यहाँ चीजें वाकई दिलचस्प हो जाती हैं। नया find_symbol टूल Copilot के agent mode को actual language-service-powered symbol navigation देता है। आपके code को text के रूप में search करने की बजाय, एजेंट अब कर सकता है:

पूरे project में किसी symbol के सभी references खोजना
type information, declarations, और scope metadata access करना
पूरी language awareness के साथ call sites पर navigate करना

व्यावहारिक रूप से इसका मतलब है: जब आप Copilot से कोई method refactor करने या call sites में parameter signature update करने को कहते हैं, तो वह वास्तव में आपके code की structure देख सकता है। अब “एजेंट ने method बदल दिया लेकिन तीन call sites miss कर दिए” जैसी स्थितियाँ नहीं होंगी।

Supported languages में C#, C++, Razor, TypeScript, और supported LSP extension वाली कोई भी language शामिल है। .NET डेवलपर्स के लिए यह एक बड़ा सुधार है — deep type hierarchies और interfaces वाले C# codebases symbol-aware navigation से बहुत फायदा उठाते हैं।

Copilot से tests profile करें

Test Explorer context menu में अब Profile with Copilot command है। कोई test select करें, profile पर click करें, और Profiling Agent automatically उसे run करके performance analyze करता है — actionable insights देने के लिए CPU usage और instrumentation data को मिलाकर।

अब manually profiler sessions configure नहीं करने, test run नहीं करने, results export नहीं करने, और flame graph पढ़ने की कोशिश नहीं करनी होगी। एजेंट analysis करता है और बताता है क्या slow है और क्यों। अभी केवल .NET के लिए, जो Visual Studio के deep .NET diagnostics integration को देखते हुए समझ में आता है।

Live debugging के दौरान performance tips

Performance optimization अब debug करने के बाद नहीं, debug करते समय होती है। जब आप code में step through करते हैं, Visual Studio execution time और performance signals inline दिखाता है। कोई slow line दिखे? Perf Tip पर click करें और Copilot से वहीं optimization suggestions माँगें।

Profiling Agent automatically runtime data capture करता है — elapsed time, CPU usage, memory behavior — और Copilot उसका उपयोग hot spots पहचानने के लिए करता है। यह performance work को आपके debugging flow का हिस्सा बनाए रखता है, न कि एक अलग काम जिसे आप टालते रहते हैं।

Solution Explorer से NuGet vulnerabilities fix करें

जब किसी NuGet package में vulnerability detect होती है, तो अब Solution Explorer में सीधे Fix with GitHub Copilot link के साथ notification दिखता है। Click करें और Copilot vulnerability analyze करता है, सही package updates recommend करता है, और उन्हें implement करता है।

उन टीमों के लिए जो dependencies up to date रखने में संघर्ष करती हैं (यानी लगभग सभी), यह “मुझे पता है vulnerability है लेकिन सही update path निकालना अपने आप में एक project है” वाली परेशानी दूर करता है।

अंतिम बात

Custom agents और skills headline हैं, लेकिन find_symbol sleeper hit है — यह मौलिक रूप से बदलता है कि Copilot .NET code refactor करते समय कितना accurate हो सकता है। Live profiling integration और vulnerability fixes के साथ मिलकर, यह अपडेट Visual Studio के AI features को demo-ready की बजाय genuinely practical बनाता है।

इसे आज़माने के लिए Visual Studio 2026 Insiders download करें।

Laptop से Production तक: दो Commands में Microsoft Foundry पर AI Agents Deploy करना

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

आप उस gap को जानते हैं जो “मेरी machine पर काम करता है” और “यह deploy हो गया है और traffic serve कर रहा है” के बीच है? AI agents के लिए, वह gap दर्दनाक रूप से चौड़ी रही है। आपको resources provision करने हैं, models deploy करने हैं, identity wire up करनी है, monitoring set up करनी है — और यह सब किसी के भी आपके agent को call करने से पहले।

Azure Developer CLI ने इसे दो-command affair बना दिया है।

नया `azd ai agent` Workflow

आइए मैं बताता हूँ यह वास्तव में कैसा दिखता है। आपके पास एक AI agent project है — मान लीजिए एक hotel concierge agent। यह locally काम करता है। आप इसे Microsoft Foundry पर चलाना चाहते हैं।

azd ai agent init
azd up

बस। दो commands। azd ai agent init आपके repo में infrastructure-as-code scaffold करता है, और azd up Azure पर सब कुछ provision करता है और आपका agent publish करता है। आपको Foundry portal में अपने agent का direct link मिलता है।

Under the Hood क्या होता है

init command आपके repo में real, inspectable Bicep templates generate करता है:

एक Foundry Resource (top-level container)
एक Foundry Project (जहाँ आपका agent रहता है)
Model deployment configuration (GPT-4o, आदि)
उचित RBAC role assignments के साथ Managed identity
Service map के लिए azure.yaml
Agent metadata और environment variables के साथ agent.yaml

यहाँ key part है: यह सब आपके पास है। यह आपके repo में versioned Bicep है। आप इसे inspect कर सकते हैं, customize कर सकते हैं, और अपने agent code के साथ commit कर सकते हैं। कोई magic black boxes नहीं।

Dev Inner Loop

मुझे जो वास्तव में पसंद है वह local development story है। जब आप agent logic पर iterate कर रहे हों, तो आप हर बार prompt बदलने पर redeploy नहीं करना चाहते:

azd ai agent run

यह आपके agent को locally start करता है। इसे azd ai agent invoke के साथ pair करें test prompts भेजने के लिए, और आपके पास एक tight feedback loop है। Code edit करें, restart करें, invoke करें, दोहराएँ।

invoke command routing के बारे में भी smart है — जब एक local agent चल रहा होता है, तो यह automatically उसे target करता है। जब नहीं, तो यह remote endpoint को hit करता है।

Real-Time Monitoring

यही वह feature है जिसने मुझे convince किया। एक बार आपका agent deploy हो जाने पर:

azd ai agent monitor --follow

आपके agent से गुज़रने वाला हर request और response real time में आपके terminal में stream होता है। Production issues debug करने के लिए, यह अमूल्य है। Log analytics खंगालने की ज़रूरत नहीं, metrics aggregate होने का इंतज़ार नहीं — आप देखते हैं कि अभी क्या हो रहा है।

पूरा Command Set

यहाँ quick reference है:

Command	क्या करता है
`azd ai agent init`	IaC के साथ एक Foundry agent project scaffold करें
`azd up`	Azure resources provision करें और agent deploy करें
`azd ai agent invoke`	Remote या local agent को prompts भेजें
`azd ai agent run`	Development के लिए agent को locally चलाएँ
`azd ai agent monitor`	Published agent से real-time logs stream करें
`azd ai agent show`	Agent health और status check करें
`azd down`	सभी Azure resources cleanup करें

.NET Developers के लिए यह क्यों मायने रखता है

भले ही announcement का sample Python-based है, infrastructure story language-agnostic है। आपके .NET agent को वही Bicep scaffolding, वही managed identity setup, वही monitoring pipeline मिलती है। और अगर आप पहले से अपने .NET Aspire apps या Azure deployments के लिए azd उपयोग कर रहे हैं, तो यह आपके मौजूदा workflow में बिल्कुल fit होता है।

AI agents के लिए deployment gap ecosystem में सबसे बड़े friction points में से एक रही है। एक working prototype से proper identity, networking, और monitoring वाले production endpoint तक पहुँचने में DevOps का एक हफ्ता नहीं लगना चाहिए। अब इसमें दो commands और कुछ minutes लगते हैं।

निष्कर्ष

azd ai agent अभी available है। अगर आप अपने AI agents deploy करना टाल रहे थे क्योंकि infrastructure setup बहुत मुश्किल लग रहा था, तो इसे एक chance दें। Frontend chat app integration सहित पूरे step-by-step के लिए पूरा walkthrough देखें।

Developer-Tools | The .NET Blog

Azure MCP Server अब .mcpb है — बिना किसी Runtime के इंस्टॉल करें

MCP Bundle क्या है?

कैसे इंस्टॉल करें

क्या कर सकते हैं

शुरुआत करने के लिए

VS Code 1.118: Copilot CLI को सेशन नाम, मॉडल बैज और TypeScript 7.0 Nightly ऑप्ट-इन मिला

Copilot CLI: सेशन को असली नाम मिलते हैं

कीबोर्ड शॉर्टकट से तेज़ सेशन स्विचिंग

चैट में मॉडल बैज

Copilot CLI में ऑटो मॉडल सिलेक्शन

TypeScript 7.0 Nightly ऑप्ट-इन

Foundry Toolboxes: AI Agents के लिए एक Unified Endpoint

Toolbox क्या है

चार pillars (आज दो available)

Practical Example

Foundry Agents में lock-in नहीं

अभी क्यों important है

निष्कर्ष

Python, TypeScript और .NET में azd Hooks: Shell Scripts से मुक्ति

Hooks क्या हैं

Detection कैसे काम करती है

Language-specific details

Python

JavaScript और TypeScript

.NET

Executor-specific configuration

.NET developers के लिए क्यों मायने रखता है

निष्कर्ष

Windows App Dev CLI v0.3: टर्मिनल से F5 डीबग और एजेंट्स के लिए UI ऑटोमेशन

winapp run: कहीं से भी F5

नया NuGet पैकेज: पैकेज्ड ऐप्स के लिए dotnet run

winapp ui: कमांड लाइन से UI ऑटोमेशन

अन्य नई सुविधाएं

कैसे प्राप्त करें

VS Code 1.117: Agents को अपनी Git Branch मिल रही है — और मैं इसके साथ हूँ

Autopilot mode आखिरकार आपकी preference याद रखता है

Agent sessions के लिए Worktree और git isolation

Subagents और agent teams

Agents input भेजने पर terminal output automatically include होता है

macOS पर self-updating Agents app

जानने लायक छोटी बातें

निष्कर्ष

Docker Sandbox, Copilot Agents को आपकी मशीन को जोखिम में डाले बिना Code Refactor करने देता है

Docker Sandbox वास्तव में क्या देता है

.NET Developers को क्यों परवाह करनी चाहिए

Security पक्ष मायने रखता है

निष्कर्ष

Terminal की देखभाल बंद करें: Aspire का Detached Mode Workflow बदल देता है

Detached mode: एक command, terminal वापस

जो चल रहा है उसे manage करना

Isolated mode के साथ मिलाएं

Coding agents के लिए यह क्यों बड़ी बात है

निष्कर्ष

Azure MCP Tools अब Visual Studio 2022 में बिल्ट-इन हैं — कोई Extension ज़रूरी नहीं

इसका वास्तव में क्या मतलब है

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

इससे आप क्या कर सकते हैं

इसे कैसे enable करें

एक ध्यान देने योग्य बात

बड़ी तस्वीर

azd update — आपके सभी Package Managers को एक Command से संभालें

यह कैसे काम करता है

छोटी सी catch

यह क्यों मायने रखता है

.NET Aspire 13.2 आपके AI Agent का सबसे अच्छा दोस्त बनना चाहता है

Aspire as agent infrastructure

Bowling bumper analogy

शुरुआत करना

Aspire का Isolated Mode Parallel Development के लिए Port Conflict के nightmare को ठीक करता है

Fix: --isolated

Real scenarios जहाँ यह चमकता है

यह under the hood कैसे काम करता है

इसे कब use करें

निष्कर्ष

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

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

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

त्वरित सुझाव

अंतिम बात

Fix: `--isolated`

CSS `@import` link resolution

नया `azd ai agent` Workflow