Posts | The .NET Blog

.NET 10 Ubuntu 26.04 LTS के साथ आया — क्या नया है

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

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

Ubuntu LTS का दिन है। Ubuntu 26.04 (Resolute Raccoon) आज लॉन्च हुआ, और हर Ubuntu LTS की तरह, यह नवीनतम .NET LTS — इस मामले में .NET 10 — के साथ आया है।

.NET 10 दो commands में install करें

sudo apt update
sudo apt install dotnet-sdk-10.0

Containers: `-noble` को `-resolute` में बदलें

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: 3ms startup, 1.4MB binary

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# 1.4MB native binary, 3ms startup

Cloud-native workloads के लिए जहाँ cold-start time मायने रखता है — Functions, containers, serverless — यह एक असली game changer है।

.NET 8 या 9 चाहिए?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

पूरी पोस्ट में cgroup v2, post-quantum cryptography और Linux 7.0 के बारे में अधिक जानकारी है।

Agent Framework में CodeAct: अपने एजेंट की लेटेंसी को आधा कैसे करें

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

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

हर एजेंट प्रोजेक्ट में एक ऐसा पल आता है जब आप ट्रेस देखते हैं और सोचते हैं: “इसमें इतना समय क्यों लग रहा है?” मॉडल ठीक है। टूल काम कर रहे हैं। लेकिन एक ऐसे परिणाम के लिए सात राउंड ट्रिप हो रहे हैं जो एक बार में की जा सकती थी।

यही वह समस्या है जिसे CodeAct हल करता है — और Agent Framework टीम ने नए agent-framework-hyperlight पैकेज के माध्यम से अल्फा सपोर्ट जारी किया है।

CodeAct क्या है?

CodeAct पैटर्न सुंदर रूप से सरल है: मॉडल को एक-एक करके टूल कॉल करने के बजाय, उसे एक execute_code टूल दें और पूरी योजना को एक छोटे Python प्रोग्राम के रूप में व्यक्त करने दें।

तरीका	समय	टोकन
पारंपरिक	27.81s	6,890
CodeAct	13.23s	2,489
सुधार	52.4%	63.9%

सुरक्षा: Hyperlight माइक्रो-VM

agent-framework-hyperlight पैकेज Hyperlight माइक्रो-VM का उपयोग करता है। प्रत्येक execute_code कॉल को अपना नया माइक्रो-VM मिलता है। स्टार्टअप मिलीसेकंड में होता है। आइसोलेशन मूल रूप से मुफ्त है।

आपके टूल होस्ट पर चलते रहते हैं। मॉडल द्वारा जेनरेट किया गया कोड सैंडबॉक्स में चलता है। यह सही विभाजन है।

न्यूनतम सेटअप

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

कब CodeAct उपयोग करें

CodeAct का उपयोग करें जब:

कार्य में कई छोटी टूल कॉल हों (लुकअप, जॉइन, गणना)
लेटेंसी और टोकन लागत महत्वपूर्ण हो
मॉडल-जेनरेटेड कोड के लिए मजबूत आइसोलेशन चाहिए

पारंपरिक टूल-कॉलिंग रखें जब:

एजेंट प्रति टर्न केवल एक-दो टूल कॉल करता हो
प्रत्येक कॉल में अलग-अलग अनुमोदन की जरूरत हो

अभी आज़माएं

pip install agent-framework-hyperlight --pre

Agent Framework ब्लॉग की पूरी पोस्ट पढ़ें।

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

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

GPT-5.5 आ गया Azure Foundry में — .NET डेवलपर्स को क्या जानना चाहिए

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

Microsoft ने अभी घोषणा की है कि GPT-5.5 Microsoft Foundry में उपलब्ध है। अगर आप Azure पर एजेंट बना रहे हैं, यह वह अपडेट है जिसका आप इंतजार कर रहे थे।

GPT-5 की प्रगति

GPT-5: रीजनिंग और गति को एक सिस्टम में एकीकृत किया
GPT-5.4: मजबूत मल्टी-स्टेप रीजनिंग, एंटरप्राइज के लिए एजेंटिक क्षमताएं
GPT-5.5: गहरा लॉन्ग-कॉन्टेक्स्ट रीजनिंग, अधिक विश्वसनीय एजेंटिक एक्सीक्यूशन, बेहतर टोकन दक्षता

वास्तव में क्या बदला

बेहतर एजेंटिक कोडिंग: GPT-5.5 बड़े कोडबेस में कॉन्टेक्स्ट बनाए रखता है, आर्किटेक्चरल विफलताओं का निदान करता है और टेस्ट आवश्यकताओं का अनुमान लगाता है।

टोकन दक्षता: कम टोकन और कम रिट्राई के साथ उच्च गुणवत्ता के आउटपुट। प्रोडक्शन में सीधे कम लागत और लेटेंसी।

मूल्य निर्धारण

मॉडल	इनपुट ($/M tokens)	कैश्ड इनपुट	आउटपुट ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

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

Foundry Agent Service आपको YAML में एजेंट परिभाषित करने या Microsoft Agent Framework, GitHub Copilot SDK, LangGraph, या OpenAI Agents SDK के साथ जोड़ने देता है — और उन्हें स्थायी फाइलसिस्टम, Microsoft Entra आइडेंटिटी और स्केल-टू-जीरो मूल्य निर्धारण के साथ एजेंट के रूप में चलाता है।

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "आप एक सहायक हैं।", name: "मेराएजेंट");

पूरी घोषणा देखें।

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 एक बड़ा रिलीज़ है (बीटा कुछ दिन पहले आया)।

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

आपका एजेंट चीजें कहाँ याद रखता है? चैट हिस्ट्री स्टोरेज का व्यावहारिक गाइड

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

जब आप एक AI एजेंट बनाते हैं, तो अधिकांश ऊर्जा मॉडल, टूल्स और प्रॉम्प्ट पर लगाते हैं। बातचीत का इतिहास कहाँ रहता है यह सवाल एक इम्प्लीमेंटेशन डिटेल लगता है — लेकिन यह सबसे महत्वपूर्ण आर्किटेक्चरल निर्णयों में से एक है जो आप लेंगे।

यह निर्धारित करता है कि उपयोगकर्ता बातचीत को ब्रांच कर सकते हैं, जवाब पूर्ववत कर सकते हैं, रीस्टार्ट के बाद सेशन फिर शुरू कर सकते हैं, और आपका डेटा कभी आपके इन्फ्रास्ट्रक्चर से बाहर जाता है या नहीं। Agent Framework टीम ने एक गहन विश्लेषण प्रकाशित किया है।

दो बुनियादी पैटर्न

सर्विस-मैनेज्ड: AI सर्विस बातचीत की स्थिति संग्रहीत करती है। आपका ऐप एक संदर्भ रखता है और सर्विस स्वचालित रूप से प्रत्येक अनुरोध में प्रासंगिक इतिहास शामिल करती है।

क्लाइंट-मैनेज्ड: आपका ऐप पूरा इतिहास रखता है और प्रत्येक अनुरोध के साथ प्रासंगिक संदेश भेजता है। सर्विस स्टेटलेस है। आप सब नियंत्रित करते हैं।

Agent Framework कैसे अमूर्त करता है

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("मेरा नाम Alice है।", session);
var second = await agent.RunAsync("मेरा नाम क्या है?", session);

प्रदाता त्वरित संदर्भ

प्रदाता	स्टोरेज	मॉडल	संपीड़न
OpenAI/Azure Chat Completions	क्लाइंट	N/A	आप
Foundry Agent Service	सर्विस	लीनियर	सर्विस
Responses API (डिफ़ॉल्ट)	सर्विस	ब्रांचिंग	सर्विस
Anthropic Claude, Ollama	क्लाइंट	N/A	आप

कैसे चुनें

ब्रांचिंग या “पूर्ववत” चाहिए? → सर्विस-मैनेज्ड Responses API
डेटा संप्रभुता चाहिए? → DB-बैक्ड प्रदाता के साथ क्लाइंट-मैनेज्ड
सिंपल चैटबॉट? → लीनियर सर्विस-मैनेज्ड ठीक है

पूर्ण निर्णय ट्री के लिए पूरी पोस्ट पढ़ें।

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 रिपॉजिटरी देखें और सभी विवरण के लिए मूल घोषणा देखें।

azd + GitHub Copilot: AI-सहायता से प्रोजेक्ट सेटअप और स्मार्ट एरर समाधान

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

क्या आप उस पल को जानते हैं जब आप Azure पर एक मौजूदा ऐप डिप्लॉय करना चाहते हैं और एक खाली azure.yaml देखकर सोचते हैं कि Express API के लिए Container Apps या App Service में से क्या चुनें? वह पल अब बहुत छोटा हो गया है।

Azure Developer CLI (azd) अब GitHub Copilot के साथ दो तरीकों से इंटीग्रेट होता है: azd init के दौरान AI-असिस्टेड प्रोजेक्ट स्कैफोल्डिंग, और डिप्लॉयमेंट फेल होने पर इंटेलिजेंट एरर ट्रबलशूटिंग। दोनों फीचर पूरी तरह टर्मिनल में रहते हैं।

azd init में Copilot के साथ सेटअप

azd init चलाने पर अब “Set up with GitHub Copilot (Preview)” विकल्प मिलता है। इसे चुनें और Copilot आपके कोडबेस का विश्लेषण करके azure.yaml, इंफ्रास्ट्रक्चर टेम्प्लेट और Bicep मॉड्यूल जनरेट करता है — आपके असली कोड के आधार पर।

azd init
# चुनें: "Set up with GitHub Copilot (Preview)"

आवश्यकताएँ:

azd 1.23.11 या नया — azd version से जाँचें या azd update से अपडेट करें
सक्रिय GitHub Copilot सब्सक्रिप्शन (Individual, Business या Enterprise)
GitHub CLI (gh) — जरूरत पड़ने पर azd लॉगिन माँगेगा

यह दोनों दिशाओं में काम करता है। नए प्रोजेक्ट के लिए? Copilot शुरू से सही Azure सर्विस कॉन्फिगर करने में मदद करता है। मौजूदा ऐप डिप्लॉय करना है? Copilot को उस पर पॉइंट करें — कोड रिस्ट्रक्चर किए बिना कॉन्फिगरेशन जनरेट हो जाएगी।

असल में क्या होता है

मान लीजिए आपके पास PostgreSQL डिपेंडेंसी वाला Node.js Express API है। Container Apps या App Service में मैन्युअली फैसला करने और Bicep लिखने की बजाय, Copilot आपका स्टैक डिटेक्ट करके जनरेट करता है:

सही language, host और build सेटिंग वाला azure.yaml
Azure Container Apps के लिए Bicep मॉड्यूल
Azure Database for PostgreSQL के लिए Bicep मॉड्यूल

और कुछ भी बदलने से पहले प्री-फ्लाइट चेक चलाता है — git वर्किंग डायरेक्टरी साफ है या नहीं, MCP सर्वर टूल कंसेंट। आपको पता होता है कि क्या बदलेगा।

Copilot से एरर ट्रबलशूटिंग

डिप्लॉयमेंट एरर अपरिहार्य हैं। गुम पैरामीटर, परमिशन इश्यू, SKU उपलब्धता — और एरर मैसेज वह नहीं बताता जो आप जानना चाहते हैं: कैसे ठीक करें।

बिना Copilot: एरर कॉपी करें → डॉक्स सर्च करें → Stack Overflow के तीन अप्रासंगिक जवाब पढ़ें → az CLI कमांड चलाएँ → दोबारा कोशिश करें। Copilot के साथ यह लूप टूट जाता है। कोई भी azd कमांड फेल होने पर तुरंत चार विकल्प मिलते हैं:

Explain — क्या गलत हुआ, सरल भाषा में
Guidance — ठीक करने के लिए स्टेप-बाय-स्टेप निर्देश
Diagnose and Guide — पूर्ण विश्लेषण + Copilot फिक्स लागू करता है (आपकी मंजूरी से) + वैकल्पिक रिट्राई
Skip — खुद संभालें

मुख्य बात: Copilot के पास आपके प्रोजेक्ट, फेल कमांड और एरर डिटेल का संदर्भ पहले से है। सुझाव आपकी स्थिति के लिए विशिष्ट हैं।

डिफ़ॉल्ट व्यवहार सेट करें

हमेशा एक ही विकल्प चुनते हैं? इंटरेक्टिव प्रॉम्प्ट स्किप करें:

azd config set copilot.errorHandling.category troubleshoot

मान: explain, guidance, troubleshoot, fix, skip। ऑटो-फिक्स और रिट्राई भी चालू कर सकते हैं:

azd config set copilot.errorHandling.fix allow

कभी भी इंटरेक्टिव मोड पर वापस:

azd config unset copilot.errorHandling.category

निष्कर्ष

azd update से नवीनतम संस्करण लें और अगले प्रोजेक्ट में azd init आज़माएँ।

मूल घोषणा यहाँ पढ़ें।

Node.js के लिए C# में नेटिव ऐडऑन लिखना .NET Native AOT के साथ

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

यहाँ एक परिदृश्य है जो मुझे पसंद है: एक टीम जो .NET टूलिंग पर काम करती थी, उसके पास C++ में लिखे Native Node.js ऐडऑन थे जो node-gyp के माध्यम से कंपाइल होते थे। यह काम करता था। लेकिन इसके लिए हर डेवलपर की मशीन पर Python इंस्टॉल होना जरूरी था — Python का पुराना वर्जन, जो सिर्फ एक ऐसे पैकेज को बिल्ड करने के लिए था जिसे टीम का कोई भी सीधे नहीं छूता।

तो उन्होंने एक बहुत उचित सवाल पूछा: हमारे पास पहले से .NET SDK इंस्टॉल है, तो हम C++ क्यों लिख रहे हैं?

जवाब था Native AOT, और परिणाम वास्तव में सुंदर है। C# Dev Kit टीम के Drew Noakes ने बताया कि उन्होंने यह कैसे किया।

बुनियादी विचार

Node.js नेटिव ऐडऑन एक शेयर्ड लाइब्रेरी है (Windows पर .dll, Linux पर .so, macOS पर .dylib) जिसे Node.js रनटाइम पर लोड कर सकता है। इंटरफेस को N-API कहा जाता है — एक स्थिर, ABI-संगत C API। N-API को परवाह नहीं है कि लाइब्रेरी किस भाषा से बनी है, बस यह कि वह सही सिंबल एक्सपोर्ट करे।

.NET Native AOT ठीक यही कर सकता है। यह आपके C# कोड को आगे से नेटिव शेयर्ड लाइब्रेरी में कंपाइल करता है। यही पूरी चाल है।

प्रोजेक्ट सेटअप

प्रोजेक्ट फाइल न्यूनतम है:

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

PublishAot SDK को dotnet publish पर शेयर्ड लाइब्रेरी बनाने के लिए कहता है।

एंट्री पॉइंट एक्सपोर्ट करना

Node.js आपकी लाइब्रेरी से napi_register_module_v1 एक्सपोर्ट करने की उम्मीद करता है। C# में, [UnmanagedCallersOnly] यही करता है:

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

u8 सफ़िक्स UTF-8 स्ट्रिंग लिटरल के साथ ReadOnlySpan<byte> बनाता है, जो बिना किसी एन्कोडिंग आवंटन के सीधे N-API को पास होता है।

TypeScript से कॉल करना

dotnet publish आपकी प्लेटफ़ॉर्म-विशिष्ट नेटिव लाइब्रेरी बनाता है। इसे .node में रीनेम करें और स्टैंडर्ड require() से उपयोग करें:

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

बस इतना। TypeScript से C# तक, बिना Python, बिना C++ के।

निष्कर्ष

C# Dev Kit टीम ने Python/C++ ओवरहेड को क्लीन C# कोड से बदला। यह पैटर्न देखने के बाद जटिल नहीं है, और यह Native AOT का एक बेहतरीन उदाहरण है।

.NET ब्लॉग पर मूल पोस्ट पढ़ें।

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, अब शुरू करने का समय है।

Azure पर आपके AI प्रयोग पैसे बर्बाद कर रहे हैं — इसे ठीक करने का तरीका यहाँ है

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

अगर आप अभी Azure पर AI-powered apps बना रहे हैं, तो आपने शायद कुछ नोटिस किया होगा: आपका cloud bill पहले जैसा नहीं दिखता। सिर्फ बड़ा नहीं — अजीब। उछल-कूद करने वाला। अनुमान लगाना मुश्किल।

Microsoft ने हाल ही में cloud cost optimization principles पर एक शानदार लेख publish किया है, और सच में, इसका timing बेहतर नहीं हो सकता था। क्योंकि AI workloads ने costs के मामले में खेल बदल दिया है।

AI Workloads क्यों अलग हैं

यहाँ बात यह है। पारंपरिक .NET workloads अपेक्षाकृत predictable होती हैं। आप अपना App Service tier जानते हैं, अपना SQL DTUs जानते हैं, मासिक खर्च का अनुमान काफी सटीक लगा सकते हैं। AI workloads? उतना नहीं।

आप multiple models test कर रहे हैं यह देखने के लिए कि कौन-सा fit है। Fine-tuning के लिए GPU-backed infrastructure spin up कर रहे हैं। Azure OpenAI को API calls कर रहे हैं जहाँ token consumption, prompt length और user behavior के आधार पर बहुत अलग-अलग होती है। हर experiment में असली पैसे लगते हैं, और सही approach पर पहुँचने से पहले आप दर्जनों experiments कर सकते हैं।

यही unpredictability लागत अनुकूलन को critical बनाती है — बाद में सोचने की बात नहीं, बल्कि पहले दिन से।

Management बनाम Optimization — अंतर जानें

लेख से एक distinction जो मुझे लगता है developers अक्सर नज़रअंदाज़ करते हैं: cost management और cost optimization में फ़र्क है।

Management tracking और reporting है। आप Azure Cost Management में budgets set करते हैं, alerts मिलते हैं, dashboards देखते हैं। यह तो बस शुरुआत है।

Optimization वह है जहाँ आप वास्तव में decisions लेते हैं। क्या आपको सच में S3 tier चाहिए, या S1 आपका load handle कर लेगा? क्या वह always-on compute instance weekends पर idle बैठी है? क्या आप training jobs के लिए spot instances उपयोग कर सकते हैं?

.NET developers के रूप में, हम code पर ध्यान देते हैं और infrastructure decisions “ops team” पर छोड़ देते हैं। लेकिन अगर आप Azure पर deploy कर रहे हैं, तो वे decisions आपकी भी हैं।

जो वास्तव में काम करता है

लेख और अपने अनुभव के आधार पर, यहाँ वह है जो वास्तव में फ़र्क डालता है:

जानें आप क्या खर्च कर रहे हैं और कहाँ। अपने resources को tag करें। गंभीरता से। अगर आप यह नहीं बता सकते कि कौन-सा project या experiment आपका budget खा रहा है, तो आप कुछ भी optimize नहीं कर सकते। उचित tagging के साथ Azure Cost Management आपका सबसे अच्छा दोस्त है।

Experiment करने से पहले guardrails set करें। Dev/test environments में महंगे SKUs को restrict करने के लिए Azure Policy उपयोग करें। अपने Azure OpenAI deployments पर spending limits set करें। Bill आने तक इंतज़ार न करें कि किसी ने weekend पर GPU cluster चलता छोड़ दिया।

लगातार rightsize करें। वह VM जो आपने prototyping के दौरान चुनी थी? वह production के लिए शायद गलत है। Azure Advisor recommendations देता है — उन्हें वास्तव में देखें। मासिक review करें, सालाना नहीं।

Lifecycle के बारे में सोचें। Dev resources को spin down होना चाहिए। Test environments को 24/7 चलने की ज़रूरत नहीं। Auto-shutdown policies उपयोग करें। AI workloads के लिए विशेष रूप से, serverless options पर विचार करें जहाँ आप execution के हिसाब से pay करते हैं बजाय compute को warm रखने के।

Value मापें, सिर्फ cost नहीं। यह भूलना आसान है। एक ऐसा model जिसकी cost ज़्यादा है लेकिन काफी बेहतर results देता है, सही choice हो सकता है। लक्ष्य कम से कम खर्च करना नहीं है — बल्कि समझदारी से खर्च करना है।

निष्कर्ष

Cloud cost optimization एक बार की सफाई नहीं है। यह एक आदत है। और AI workloads के साथ खर्च पहले से कम predictable होता जा रहा है, इस आदत को जल्दी बनाने से बाद में तकलीफदेह surprises से बचाव होता है।

अगर आप Azure पर build करने वाले .NET developer हैं, तो अपने cloud bill को वैसे ही treat करना शुरू करें जैसे आप अपना code treat करते हैं — नियमित रूप से review करें, जब messy हो जाए तो refactor करें, और कभी भी यह जाने बिना deploy न करें कि इसकी लागत क्या होगी।

Foundry का RFT सस्ता और स्मार्ट हो गया — यहाँ जानिए क्या बदला

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

अगर आप fine-tuned models पर निर्भर .NET apps बना रहे हैं, तो इस महीने के Foundry updates पर ध्यान देने लायक हैं। Reinforcement Fine-Tuning अब और accessible और काफी सस्ती हो गई है।

पूरी जानकारी official announcement में है, लेकिन यहाँ practical breakdown है।

o4-mini के लिए Global Training

o4-mini reasoning-heavy और agentic workloads के लिए go-to model है। बड़ी खबर: अब आप Standard training की तुलना में कम per-token training rates के साथ 13+ Azure regions से fine-tuning jobs launch कर सकते हैं। वही infrastructure, वही quality, व्यापक पहुँच।

अगर आपकी team geographies में फैली हुई है, तो यह मायने रखता है। अब आप training के लिए कुछ ही regions तक सीमित नहीं हैं।

Global training job शुरू करने के लिए REST API call यहाँ है:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

वह trainingType: globalstandard flag ही मुख्य अंतर है।

नए Model Graders: GPT-4.1 Family

Graders वह reward signal define करते हैं जिसके आधार पर आपका model optimize करता है। अब तक, model-based graders models के एक छोटे set तक सीमित थे। अब आपको तीन नए विकल्प मिलते हैं: GPT-4.1, GPT-4.1-mini, और GPT-4.1-nano।

Deterministic graders की बजाय model graders कब use करें? जब आपका task output open-ended हो, जब आपको कई dimensions में partial credit scoring चाहिए, या जब आप ऐसे agentic workflows बना रहे हों जहाँ tool-call correctness semantic context पर निर्भर करती है।

बात यह है — tiering strategy practical है:

GPT-4.1-nano शुरुआती iterations के लिए। कम cost, fast feedback loops।
GPT-4.1-mini जब आपका grading rubric stable हो और आपको higher fidelity चाहिए।
GPT-4.1 production grading या complex rubrics के लिए जहाँ हर scoring decision मायने रखती है।

आप एक ही RFT job में grader types भी mix कर सकते हैं। “correct answer” dimension के लिए string-match और reasoning quality evaluate करने के लिए model grader। यह flexibility ही इसे real workloads के लिए उपयोगी बनाती है।

RFT Data Format की समस्या

यह लोगों को अटकाती है। RFT data format SFT से अलग है। हर row का आखिरी message User या Developer role का होना चाहिए — Assistant का नहीं। Expected answer एक top-level key जैसे reference_answer में जाता है जिसे grader directly reference करता है।

अगर आप supervised fine-tuning कर रहे हैं और RFT पर switch करना चाहते हैं, तो आपको अपना training data restructure करना होगा। यह step skip न करें वरना आपके jobs silently fail होंगे।

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

अगर आप Azure OpenAI SDK के ज़रिए .NET apps से fine-tuned models call कर रहे हैं, तो सस्ती training का मतलब है कि आप अधिक aggressively iterate कर सकते हैं। Model grader options का मतलब है कि आप nuanced tasks के लिए fine-tune कर सकते हैं — सिर्फ exact-match scenarios नहीं। और GitHub पर best practices guide आपका real debugging time बचाएगी।

छोटे से शुरू करें। दस से सौ samples। Simple grader। Loop validate करें। फिर scale करें।

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 प्राप्त करें।

.NET MAUI Maps में Pin Clustering आखिरकार आया — एक Property, Zero परेशानी

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

आप उस moment को जानते हैं जब आप सौ pins वाला map load करते हैं और पूरी चीज़ एक unreadable blob बन जाती है? हाँ, यही तब तक .NET MAUI Maps का experience था। अब नहीं।

David Ortinau ने अभी announce किया कि .NET MAUI 11 Preview 3 Android और iOS/Mac Catalyst पर out of the box pin clustering ship करता है। और सबसे अच्छी बात — इसे enable करना बेहद simple है।

एक property सबको control करे

<maps:Map IsClusteringEnabled="True" />

बस इतना। Nearby pins count badge के साथ clusters में group हो जाते हैं। Zoom in करें और वे expand होते हैं। Zoom out करें और वे collapse होते हैं। वह behavior जो users किसी भी modern map से expect करते हैं — और अब आपको यह एक single property से मिलता है।

स्वतंत्र clustering groups

यहाँ यह interesting हो जाता है। सभी pins को एक साथ cluster नहीं होना चाहिए। Coffee shops और parks अलग-अलग चीज़ें हैं, और आपके map को यह पता होना चाहिए।

ClusteringIdentifier property आपको pins को independent groups में अलग करने देती है:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Same identifier वाले pins एक साथ cluster होते हैं। अलग-अलग identifiers independent clusters बनाते हैं भले ही वे geographically करीब हों। कोई identifier नहीं? Default group। साफ़ और predictable।

Cluster taps handle करना

जब कोई user cluster tap करता है, तो आपको ClusterClicked event मिलती है जिसमें आपको जो चाहिए वह सब होता है:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Default zoom-to-cluster behavior suppress करने के लिए:
 // e.Handled = true;
};

Event args आपको Pins (cluster में pins), Location (geographic center), और Handled (default zoom override करने के लिए true set करें) देते हैं। Simple, practical, exactly वही जो आप expect करते।

Platform से जुड़ी ज़रूरी बातें

Android पर, clustering एक custom grid-based algorithm का उपयोग करती है जो zoom changes पर recalculate होती है — कोई external dependencies नहीं। iOS और Mac Catalyst पर, यह MapKit का native MKClusterAnnotation support leverage करता है, जिसका मतलब है smooth, platform-native animations।

यह उन cases में से एक है जहाँ MAUI team ने सही call किया — जहाँ समझ में आए वहाँ platform पर lean करो।

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

.NET MAUI में Pin clustering सबसे ज़्यादा requested features में से एक रही है (issue #11811), और इसकी वजह है। हर app जो map पर locations दिखाती है — delivery tracking, store locators, real estate — इसकी ज़रूरत होती है। पहले आपको इसे खुद बनाना पड़ता था या किसी third-party library को लाना पड़ता था। अब यह built in है।

हम .NET developers के लिए जो cross-platform mobile apps बना रहे हैं, यह उस तरह का quality-of-life improvement है जो MAUI को map-heavy scenarios के लिए genuinely practical choice बनाता है।

शुरुआत करें

.NET 11 Preview 3 install करें और .NET MAUI workload update करें। Maps sample में एक नया Clustering page है जिसे आप तुरंत try कर सकते हैं।

जाएं, इसके साथ कुछ बनाएं — और अपने maps को finally सांस लेने दें।

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, उतना बेहतर।

.NET April 2026 Servicing — Security Patches जो आपको आज Apply करने चाहिए

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

.NET और .NET Framework के लिए April 2026 servicing updates आ गए हैं, और इसमें security fixes हैं जिन्हें आप जल्द apply करना चाहेंगे। छह CVEs patch किए गए हैं, जिनमें दो remote code execution (RCE) vulnerabilities शामिल हैं।

क्या Patch किया गया है

यहाँ quick summary है:

CVE	प्रकार	प्रभावित करता है
CVE-2026-26171	Security Feature Bypass	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Remote Code Execution	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Remote Code Execution	.NET 10, 9, 8
CVE-2026-32203	Denial of Service	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Denial of Service	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denial of Service	.NET Framework 2.0–4.8.1

दोनों RCE CVEs (CVE-2026-32178 और CVE-2026-33116) .NET versions की सबसे broad range को affect करते हैं और इन्हें priority देनी चाहिए।

Updated Versions

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

सभी usual channels पर available हैं — dotnet.microsoft.com, MCR पर container images, और Linux package managers।

क्या करें

अपने projects और CI/CD pipelines को latest patch versions पर update करें। अगर आप containers चला रहे हैं, तो latest images pull करें। अगर आप .NET Framework पर हैं, तो corresponding patches के लिए .NET Framework release notes देखें।

Production में .NET 10 चला रहे लोगों के लिए (यह current release है), 10.0.6 एक mandatory update है। वही .NET 9.0.15 और .NET 8.0.26 के लिए भी लागू होता है अगर आप उन LTS tracks पर हैं। दो RCE vulnerabilities ऐसी चीज़ नहीं हैं जिन्हें आप टालें।

Aspire 13.2 में MongoDB EF Core और Azure Data Lake — दो Integrations जो आज़माने लायक हैं

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

Aspire 13.2 अभी दो नए database integrations के साथ आया है जो आपका ध्यान आकर्षित करने के लायक हैं: MongoDB Entity Framework Core और Azure Data Lake Storage। अगर आप Aspire app में EF Core के साथ MongoDB उपयोग करना चाहते थे, या proper service discovery के साथ data lake workloads wire up करने की ज़रूरत थी, तो यह release दोनों deliver करती है।

MongoDB meets EF Core in Aspire

यह वो है जिसके बारे में मैं सबसे ज़्यादा excited हूँ। Aspire ने काफी समय से MongoDB को support किया है, लेकिन यह हमेशा raw driver था — कोई EF Core नहीं, कोई DbContext नहीं, documents के खिलाफ कोई LINQ queries नहीं। अब आपको MongoDB के साथ पूरा EF Core experience मिलता है, plus Aspire के automatic health checks और service discovery।

इसे setup करना typical Aspire pattern है। अपने AppHost में:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

फिर अपने consuming project में, EF Core integration जोड़ें:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

और अपना DbContext register करें:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

वहाँ से, यह standard EF Core है। अपनी entities define करें, अपने DbContext को किसी भी दूसरे provider की तरह उपयोग करें। Integration connection pooling, OpenTelemetry traces और health checks को behind the scenes handle करता है।

.NET developers के लिए जो raw driver के साथ MongoDB उपयोग कर रहे थे और manually connection strings wire up कर रहे थे, यह एक अच्छा quality-of-life upgrade है। आपको Aspire की service discovery खोए बिना पूरा EF Core abstraction मिलता है।

Azure Data Lake Storage पार्टी में शामिल हुई

दूसरा बड़ा addition एक Azure Data Lake Storage (ADLS) integration है। अगर आप data pipelines, ETL processes, या analytics platforms बना रहे हैं, तो अब आप Data Lake resources को उसी तरह wire up कर सकते हैं जैसे आप किसी दूसरी Aspire dependency को करते हैं।

AppHost में:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Consuming project में:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

कोई manual connection string management नहीं, कोई credential hunting नहीं। Aspire resources provision करता है और उन्हें inject करता है। जो लोग cloud-native .NET apps बना रहे हैं जो operational data और analytics workloads दोनों को handle करती हैं, उनके लिए यह data lake को Aspire model में एक first-class citizen जैसा महसूस कराता है।

छोटे fixes जो मायने रखते हैं

Headline features के अलावा, कुछ quality-of-life improvements भी हैं जो ध्यान देने योग्य हैं:

MongoDB connection string fix — database name से पहले forward slash अब सही तरीके से handle होता है। अगर आप इसके आसपास काम कर रहे थे, तो आप वह workaround हटा सकते हैं
SQL Server exports — Aspire.Hosting.SqlServer अब finer-grained control के लिए additional server configuration options export करता है
Emulator updates — ServiceBus emulator 2.0.0, App Configuration emulator 1.0.2, और CosmosDB का preview emulator अब readiness check शामिल करता है
Azure Managed Redis — अब default रूप से rediss:// (Redis Secure) है, इसलिए connections out of the box encrypted हैं

वह आखिरी वाला subtle लेकिन important है — default रूप से encrypted Redis का मतलब है production में configure करने के लिए एक कम चीज़।

अंत में

Aspire 13.2 एक incremental release है, लेकिन MongoDB EF Core और Data Lake integrations real gaps भरते हैं। अगर आप Aspire में MongoDB के साथ proper EF Core support का इंतज़ार कर रहे थे, या Data Lake को first-class dependency बनाने की ज़रूरत थी, तो 13.2 पर upgrade करें और इन्हें आज़माएं। aspire add command आपको ज़रूरत की सब कुछ scaffold कर देती है।

अधिक details के लिए full release notes पढ़ें, और पूरी list के लिए integration gallery देखें।

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 पढ़ें।

Azure DevOps Server अप्रैल 2026 पैच — PR Completion फिक्स और Security अपडेट

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

self-hosted Azure DevOps Server चला रही teams के लिए एक ज़रूरी सूचना: Microsoft ने अप्रैल 2026 के लिए Patch 3 release किया है जिसमें तीन targeted fixes हैं।

क्या ठीक किया गया

Pull request completion failures — work item auto-completion के दौरान एक null reference exception से PR merges fail हो सकती थीं। अगर आपको random PR completion errors आती थीं, तो संभवतः यही कारण था
Sign-out redirect validation — sign-out के दौरान संभावित malicious redirects को रोकने के लिए बेहतर validation। यह एक security fix है जिसे जल्दी लागू करना उचित है
GitHub Enterprise Server PAT connections — GitHub Enterprise Server में Personal Access Token connections बनाना टूटा हुआ था, अब यह ठीक हो गया है

Update कैसे करें

Patch 3 download करें और installer चलाएं। यह verify करने के लिए कि patch लागू हुआ है:

<patch-installer>.exe CheckInstall

अगर आप Azure DevOps Server on-premises चला रहे हैं, तो Microsoft दृढ़ता से सुरक्षा और विश्वसनीयता दोनों के लिए नवीनतम patch पर रहने की सलाह देता है। पूरी जानकारी के लिए release notes देखें।

Azure Smart Tier GA हुआ — Lifecycle Rules के बिना स्वचालित Blob Storage लागत अनुकूलन

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

अगर आपने कभी Azure Blob Storage lifecycle policies tune करने में समय बिताया है और फिर देखा है कि access patterns बदलने पर वे ध्वस्त हो जाती हैं, तो यह खबर आपके लिए है। Microsoft ने Azure Blob और Data Lake Storage के लिए smart tier की general availability की घोषणा की — यह एक fully managed tiering capability है जो वास्तविक उपयोग के आधार पर objects को hot, cool, और cold tiers के बीच स्वचालित रूप से ले जाती है।

Smart tier वास्तव में क्या करता है

अवधारणा सीधी है: smart tier आपके storage account में हर object के last access time का लगातार मूल्यांकन करता है। बार-बार access होने वाला data hot में रहता है, 30 दिनों बाद निष्क्रिय data cool में चला जाता है, और फिर 60 दिनों बाद cold में। जब data फिर से access होता है, तो वो तुरंत hot पर वापस आ जाता है। चक्र फिर से शुरू होता है।

Configure करने के लिए कोई lifecycle rules नहीं। Access pattern predictions नहीं। कोई manual tuning नहीं।

Preview के दौरान, Microsoft ने बताया कि smart-tier-managed capacity का 50% से अधिक हिस्सा actual access patterns के आधार पर स्वचालित रूप से cooler tiers में चला गया। बड़े storage accounts के लिए यह एक सार्थक cost reduction है।

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

अगर आप ऐसी applications बना रहे हैं जो logs, telemetry, analytics data, या किसी भी तरह का growing data estate generate करती हैं — और सच में, कौन नहीं बना रहा — तो storage costs तेज़ी से बढ़ती हैं। पारंपरिक approach थी lifecycle management policies लिखना, उन्हें test करना, और फिर जब app के access patterns बदलें तो फिर से tune करना। Smart tier उस पूरे workflow को हटा देता है।

कुछ व्यावहारिक scenarios जहाँ यह मदद करता है:

Application telemetry और logs — debugging के समय hot, कुछ हफ्तों बाद शायद ही access
Data pipelines और ETL outputs — processing के दौरान भारी access, फिर mostly cold
User-generated content — recent uploads hot हैं, पुराना content धीरे-धीरे ठंडा होता है
Backup और archival data — compliance के लिए कभी-कभी access, mostly idle

इसे Setup करना

Smart tier enable करना एक बार का configuration है:

नए accounts: storage account creation के दौरान smart tier को default access tier के रूप में चुनें (zonal redundancy ज़रूरी है)
मौजूदा accounts: अपने current default से blob access tier को smart tier में switch करें

128 KiB से छोटे objects hot में रहते हैं और monitoring fee नहीं लगती। बाकी सब के लिए, आप standard hot/cool/cold capacity rates pay करते हैं बिना tier transition charges, early deletion fees, या data retrieval costs के। Per object एक monthly monitoring fee orchestration को cover करती है।

जो tradeoff जाननी चाहिए

Smart tier के tiering rules static हैं (30 दिन → cool, 90 दिन → cold)। अगर आपको custom thresholds चाहिए — जैसे किसी specific workload के लिए 7 दिनों में cool पर जाना — तो lifecycle rules अभी भी सही तरीका है। और दोनों को mix न करें: smart-tier-managed objects पर lifecycle rules use करने से बचें, क्योंकि वे conflict कर सकते हैं।

निष्कर्ष

यह क्रांतिकारी नहीं है, लेकिन यह एक real operational सिरदर्द हल करता है। अगर आप बढ़ते blob storage accounts manage करते हैं और lifecycle policies maintain करते-करते थक गए हैं, तो smart tier enable करें और Azure को यह handle करने दें। यह आज लगभग सभी zonal public cloud regions में उपलब्ध है।

Azure पर अपने AI Agents को कहाँ Host करें? एक Practical Decision Guide

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

अगर आप अभी .NET के साथ AI agents build कर रहे हैं, तो आपने शायद एक बात notice की होगी: Azure पर उन्हें host करने के बहुत तरीके हैं। Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — और ये सब तब तक reasonable लगते हैं जब तक आपको actually एक चुनना नहीं पड़ता। Microsoft ने हाल ही में Azure AI agent hosting का एक comprehensive guide publish किया है जो इसे clear करता है, और मैं इसे एक practical .NET developer perspective से break down करना चाहता हूँ।

एक नज़र में छह options

यहाँ बताया गया है कि मैं इस landscape को कैसे summarize करूँगा:

Option	सबसे अच्छा	आप manage करते हैं
Container Apps	K8s complexity के बिना full container control	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	सब कुछ (यही तो point है)
Azure Functions	Event-driven, short-running agent tasks	ज़्यादा नहीं — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	लगभग कुछ नहीं
Foundry Hosted Agents	Custom framework agents with managed infra	केवल आपका agent code

पहले चार general-purpose compute हैं — आप उन पर agents चला सकते हैं, लेकिन वे इसके लिए design नहीं किए गए। अंतिम दो agent-native हैं: वे conversations, tool calls, और agent lifecycles को first-class concepts के रूप में समझते हैं।

Foundry Hosted Agents — .NET agent developers के लिए sweet spot

यहाँ जो मेरा ध्यान खींचा। Foundry Hosted Agents बीच में sit करते हैं: आपको अपना code चलाने की flexibility मिलती है (Semantic Kernel, Agent Framework, LangGraph — जो भी) लेकिन platform infrastructure, observability, और conversation management handle करता है।

मुख्य piece है Hosting Adapter — एक thin abstraction layer जो आपके agent framework को Foundry platform से bridge करता है। Microsoft Agent Framework के लिए, यह इस तरह दिखता है:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

यही आपकी पूरी hosting story है। Adapter protocol translation, server-sent events के ज़रिये streaming, conversation history, और OpenTelemetry tracing handle करता है — सब automatically। कोई custom middleware नहीं, कोई manual plumbing नहीं।

Deploy करना genuinely simple है

मैंने पहले Container Apps पर agents deploy किए हैं और यह काम करता है, लेकिन आप state management और observability के लिए काफी glue code लिखते हैं। Hosted Agents और azd के साथ, deployment है:

# AI agent extension install करें
azd ext install azure.ai.agents

# Template से init करें
azd ai agent init

# Build, push, deploy — हो गया
azd up

वह single azd up आपका container build करता है, उसे ACR में push करता है, Foundry project provision करता है, model endpoints deploy करता है, और आपका agent start करता है। पाँच steps एक command में।

Built-in conversation management

यही production में सबसे ज़्यादा समय बचाता है। अपना conversation state store बनाने की बजाय, Hosted Agents इसे natively handle करते हैं:

# एक persistent conversation बनाएं
conversation = openai_client.conversations.create()

# पहला turn
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# दूसरा turn — context preserve होता है
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

कोई Redis नहीं। कोई Cosmos DB session store नहीं। Message serialization के लिए कोई custom middleware नहीं। Platform बस इसे handle कर लेता है।

मेरा decision framework

सभी छह options को देखने के बाद, यह मेरा quick mental model है:

क्या आपको zero infrastructure चाहिए? → Foundry Agents (portal/SDK, no containers)
क्या आपके पास custom agent code है लेकिन managed hosting चाहिए? → Foundry Hosted Agents
क्या आपको event-driven, short-lived agent tasks चाहिए? → Azure Functions
क्या आपको K8s के बिना maximum container control चाहिए? → Container Apps
क्या आपको strict compliance और multi-cluster चाहिए? → AKS
क्या आपके पास predictable traffic वाला simple HTTP agent है? → App Service

Semantic Kernel या Microsoft Agent Framework के साथ build करने वाले ज़्यादातर .NET developers के लिए, Hosted Agents likely सही starting point है। आपको scale-to-zero, built-in OpenTelemetry, conversation management, और framework flexibility मिलती है — Kubernetes manage किए बिना या अपनी observability stack wire up किए बिना।

निष्कर्ष

Azure पर agent hosting landscape तेज़ी से mature हो रहा है। अगर आप आज एक नया AI agent project शुरू कर रहे हैं, तो habit से Container Apps या AKS पर जाने से पहले Foundry Hosted Agents को seriously consider करें। Managed infrastructure real time बचाती है, और hosting adapter pattern आपको अपना framework choice रखने देता है।

Microsoft का पूरा guide और working examples के लिए Foundry Samples repo देखें।

.NET में Agent Skills अब काफी लचीली हो गई हैं

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

अगर आप Microsoft Agent Framework के साथ agents बना रहे हैं, तो आप यह drill जानते हैं: skills define करें, उन्हें provider में wire करें, और agent को decide करने दें कि कौन-सी invoke करनी है। नया यह है कि आप उन skills को कैसे बनाते हैं — और flexibility में जो उछाल आई है वह काफी बड़ी है।

ताज़ा update agent skills के लिए तीन अलग authoring patterns introduce करता है: file-based, class-based, और inline code-defined। तीनों एक single AgentSkillsProviderBuilder में plug होते हैं, यानी आप बिना किसी routing logic या special glue code के mix और match कर सकते हैं। चलिए हर एक को walk through करते हैं और देखते हैं कि आप उसे कब choose करेंगे।

File-based skills: शुरुआती बिंदु

File-based skills बिल्कुल वैसी ही हैं जैसी सुनाई देती हैं — disk पर एक directory जिसमें SKILL.md file, optional scripts, और reference documents हों। अपने agent को नई capabilities देने का यह सबसे सीधा तरीका है:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md frontmatter skill का name और description declare करता है, और instructions section agent को बताता है कि scripts और references कैसे use करें:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

फिर script execution के लिए SubprocessScriptRunner.RunAsync के साथ wire up करें:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Agent skill को automatically discover करता है और account status check करने की ज़रूरत पड़ने पर provisioning script invoke करता है। साफ और सरल।

Class-based skills: NuGet के ज़रिए ship करें

Teams के लिए यहाँ दिलचस्प बात है। Class-based skills AgentClassSkill<T> से derive होती हैं और [AgentSkillResource] और [AgentSkillScript] जैसे attributes use करती हैं ताकि framework reflection के ज़रिए सब कुछ discover कर सके:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

यहाँ खूबसूरती यह है कि एक team इसे NuGet package के रूप में package कर सकती है। आप इसे अपने project में add करें, builder में drop करें, और यह आपकी file-based skills के साथ बिना किसी coordination के काम करता है:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

दोनों skills agent के system prompt में दिखाई देती हैं। Agent conversation के आधार पर decide करता है कि कौन-सी use करनी है — कोई routing code नहीं चाहिए।

Inline skills: त्वरित bridge

वह पल जब आप जानते हैं कि दूसरी team ठीक वही skill बना रही है जो आपको चाहिए, लेकिन वह एक sprint के लिए ship नहीं होगी? AgentInlineSkill आपका bridge है:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

इसे दूसरों की तरह ही builder में add करें:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

जब NuGet package आखिरकार ship होगा, तो आप inline skill को class-based से swap कर देते हैं। Agent को फ़र्क नहीं पड़ता।

लेकिन inline skills सिर्फ bridge के लिए नहीं हैं। ये तब भी सही choice हैं जब आपको runtime पर dynamically skills generate करनी हों — config से load की गई हर business unit के लिए एक skill सोचें — या जब किसी script को local state पर close करना हो जो किसी DI container में नहीं जाती।

Script approval: human-in-the-loop

Production agents बनाने वाले हम .NET developers के लिए, यह वह हिस्सा है जो deployment conversations को actually unblock करता है। कुछ scripts के real consequences होते हैं — किसी को benefits में enroll करना, production infra query करना। UseScriptApproval on करें और agent किसी भी script execute करने से पहले रुक जाता है:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

जब agent कोई script run करना चाहता है, तो वह approval request return करता है। आपकी app decision collect करती है — approve या reject — और agent उसी के अनुसार continue करता है। Regulated environments में, यही फ़र्क है “हम इसे deploy कर सकते हैं” और “legal ने मना कर दिया” के बीच।

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

असली power कोई एक authoring pattern नहीं है — यह composition है। आप:

छोटे से शुरू कर सकते हैं file-based skill से, instructions पर iterate करें, और बिना C# लिखे ship करें
Reusable skills ship कर सकते हैं NuGet packages के रूप में जिन्हें दूसरी teams एक line से add कर सकती हैं
Gaps को bridge कर सकते हैं inline skills से जब आपको अभी कुछ चाहिए
Shared skill directories को filter कर सकते हैं predicates से ताकि आपका agent सिर्फ वही load करे जो उसे चाहिए
Human oversight add कर सकते हैं उन scripts के लिए जो production systems को touch करती हैं

ये सभी AgentSkillsProviderBuilder के ज़रिए compose होते हैं। कोई special routing नहीं, कोई conditional logic नहीं, कोई skill type checks नहीं।

Wrapping up

.NET में Agent skills के पास अब एक genuinely flexible authoring model है। चाहे आप file-based skills से prototype sketch करने वाले solo developer हों या NuGet के ज़रिए packaged capabilities ship करने वाली enterprise team, patterns fit हैं। और script approval mechanism इसे उन environments के लिए production-ready बनाता है जहाँ आपको वह human checkpoint चाहिए।

पूरे walkthrough के लिए original announcement, Microsoft Learn पर Agent Skills documentation, और hands-on होने के लिए .NET samples on GitHub देखें।

Azure MCP Server 2.0 आया — Self-Hosted Agentic Cloud Automation यहाँ है

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

अगर आप हाल ही में MCP और Azure के साथ कुछ build कर रहे हैं, तो आप शायद जानते हैं कि local experience अच्छी तरह काम करती है। लेकिन जब आपको यह setup team भर में share करना हो? वहाँ चीजें complicated हो जाती थीं।

अब नहीं। Azure MCP Server 2.0 stable हो गया, और headline feature वही है जो enterprise teams ने माँगी थी: self-hosted remote MCP server support।

Azure MCP Server क्या है?

Azure MCP Server Model Context Protocol specification implement करता है और Azure capabilities को structured, discoverable tools के रूप में expose करता है। Numbers खुद बोलते हैं: 57 Azure services में 276 MCP tools।

बड़ी बात: self-hosted remote deployments

Real team scenario में आपको चाहिए:

Developers और internal agent systems के लिए shared access
Centralized configuration
Enterprise network और policy boundaries
CI/CD pipelines में integration

Azure MCP Server 2.0 यह सब address करता है। Auth के लिए दो options:

Managed Identity — Microsoft Foundry के साथ
On-Behalf-Of (OBO) flow — user के actual permissions के साथ

Security hardening

2.0 release में जोड़ा गया:

Stronger endpoint validation
Query-oriented tools में injection patterns के खिलाफ protection
Dev environments के लिए tighter isolation controls

Getting started

GitHub Repo — source code, docs
Docker Image — containerized deployment
VS Code Extension — IDE integration
Self-hosting guide — 2.0 का flagship feature

Azure MCP Server 2.0 enterprise teams के लिए MCP को real agentic workflows के लिए ready बनाता है।

.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 पढ़ें।

Agentic Platform Engineering हकीकत बन रही है — Git-APE दिखाता है कैसे

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

Platform engineering उन terms में से एक रही है जो conference talks में बहुत अच्छी लगती है, लेकिन आमतौर पर इसका मतलब होता है “हमने एक internal portal और एक Terraform wrapper बनाया।” असली वादा — self-service infrastructure जो वास्तव में safe, governed और fast हो — हमेशा कुछ कदम दूर रही है।

Azure team ने अभी अपनी agentic platform engineering series का Part 2 प्रकाशित किया, और यह पूरी तरह hands-on implementation के बारे में है। वे इसे Git-APE कहते हैं (हाँ, acronym जानबूझकर है), और यह एक open-source project है जो GitHub Copilot agents plus Azure MCP servers का उपयोग करके natural-language requests को validated, deployed infrastructure में बदलता है।

Git-APE वास्तव में क्या करता है

मूल विचार: developers को Terraform modules सीखने, portal UIs navigate करने, या platform team को tickets file करने की बजाय, वे एक Copilot agent से बात करते हैं। Agent intent को समझता है, Infrastructure-as-Code generate करता है, उसे policies के खिलाफ validate करता है, और deploy करता है — सब VS Code के अंदर।

यहाँ setup है:

git clone https://github.com/Azure/git-ape
cd git-ape

VS Code में workspace खोलें, और agent configuration files GitHub Copilot द्वारा auto-discovered हो जाती हैं। आप agent के साथ directly interact करते हैं:

@git-ape deploy a function app with storage in West Europe

Agent Azure services के साथ interact करने के लिए Azure MCP Server का उपयोग करता है। VS Code settings में MCP configuration specific capabilities enable करता है:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

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

जो लोग Azure पर build कर रहे हैं, उनके लिए यह platform engineering की conversation को “हम एक portal कैसे बनाएं” से “हम अपने guardrails को APIs के रूप में कैसे describe करें” की ओर shift करता है। जब आपके platform का interface एक AI agent हो, तो आपके constraints और policies की गुणवत्ता ही product बन जाती है।

Part 1 blog ने theory रखी: well-described APIs, control schemas, और explicit guardrails platforms को agent-ready बनाते हैं। Part 2 actual tooling ship करके साबित करता है कि यह काम करता है। Agent अंधाधुंध resources generate नहीं करता — यह best practices के खिलाफ validate करता है, naming conventions का सम्मान करता है, और आपके organization की policies लागू करता है।

Clean-up भी उतनी ही आसान है:

@git-ape destroy my-resource-group

मेरी राय

सच कहूँ तो — यह specific tool से ज़्यादा pattern के बारे में है। Git-APE खुद एक demo/reference architecture है। लेकिन underlying idea — agents आपके platform का interface, MCP protocol, GitHub Copilot host — यही वह जगह है जहाँ enterprise developer experience जा रही है।

अगर आप एक platform team हैं जो देख रहे हैं कि अपने internal tooling को agent-friendly कैसे बनाएं, तो इससे बेहतर कोई starting point नहीं है। और अगर आप एक .NET developer हैं जो सोच रहे हैं कि यह आपकी दुनिया से कैसे जुड़ता है: Azure MCP Server और GitHub Copilot agents किसी भी Azure workload के साथ काम करते हैं। आपकी ASP.NET Core API, आपका .NET Aspire stack, आपके containerized microservices — यह सब एक agentic deployment flow का target हो सकता है।

अंत में

Git-APE agentic platform engineering का एक प्रारंभिक लेकिन ठोस रूप है। repo clone करें, demo आज़माएं, और सोचना शुरू करें कि आपके platform की APIs और policies को एक agent द्वारा safely उपयोग किए जाने के लिए कैसा दिखना होगा।

walkthrough और video demos के लिए पूरा 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 करें।

Azure Functions पर अपने MCP Servers को Foundry Agents से कनेक्ट करें — यहाँ जानिए कैसे

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

MCP ecosystem के बारे में मुझे एक बात बहुत पसंद है: आप अपना server एक बार बनाते हैं, और यह हर जगह काम करता है। VS Code, Visual Studio, Cursor, ChatGPT — हर MCP client आपके tools discover और use कर सकता है। अब Microsoft उस list में एक और consumer जोड़ रहा है: Foundry agents।

Azure SDK team की Lily Ma ने एक practical guide publish की है जो Azure Functions पर deploy किए गए MCP servers को Microsoft Foundry agents से connect करने के बारे में है। अगर आपके पास पहले से एक MCP server है, तो यह pure value-add है — कोई rebuilding की ज़रूरत नहीं।

यह combination क्यों समझ में आता है

Azure Functions आपको scalable infrastructure, built-in auth, और MCP servers host करने के लिए serverless billing देता है। Microsoft Foundry आपको AI agents देता है जो reason, plan, और actions ले सकते हैं। दोनों को connect करने का मतलब है कि आपके custom tools — database query करना, business API call करना, validation logic चलाना — ऐसी capabilities बन जाती हैं जिन्हें enterprise AI agents autonomously discover और use कर सकते हैं।

मुख्य बात: आपका MCP server वैसा ही रहता है। आप बस Foundry को एक और consumer के रूप में जोड़ रहे हैं। वही tools जो आपके VS Code setup में काम करते हैं, अब एक AI agent को power करते हैं जिससे आपकी team या customers interact करते हैं।

Authentication के विकल्प

यहीं पर यह post वास्तव में value add करती है। आपके scenario के अनुसार चार auth methods:

Method	Use Case
Key-based (default)	Development या Entra auth के बिना servers
Microsoft Entra	Managed identities के साथ production
OAuth identity passthrough	Production जहाँ हर user individually authenticate करता है
Unauthenticated	Dev/testing या केवल public data

Production के लिए, agent identity के साथ Microsoft Entra recommended path है। OAuth identity passthrough तब है जब user context मायने रखता है — agent users को sign in के लिए prompt करता है, और हर request user का अपना token carry करती है।

इसे कैसे सेट करें

High-level flow:

अपना MCP server Azure Functions पर deploy करें — .NET, Python, TypeScript, और Java के लिए samples उपलब्ध हैं
अपने function app पर built-in MCP authentication enable करें
अपना endpoint URL पाएं — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Foundry में MCP server को tool के रूप में जोड़ें — portal में अपना agent navigate करें, एक नया MCP tool जोड़ें, endpoint और credentials दें

फिर Agent Builder playground में एक ऐसा prompt भेजकर test करें जो आपके किसी tool को trigger करे।

मेरा नज़रिया

यहाँ composability की कहानी वाकई मज़बूत हो रही है। अपना MCP server एक बार .NET (या Python, TypeScript, Java) में बनाएं, Azure Functions पर deploy करें, और हर MCP-compatible client इसे use कर सकता है — coding tools, chat apps, और अब enterprise AI agents। यह एक “एक बार लिखो, हर जगह use करो” pattern है जो वास्तव में काम करता है।

.NET developers के लिए विशेष रूप से, Azure Functions MCP extension इसे straightforward बनाता है। आप अपने tools को Azure Functions के रूप में define करें, deploy करें, और आपके पास Azure Functions की सभी security और scaling के साथ एक production-grade MCP server है।

निष्कर्ष

अगर आपके पास Azure Functions पर चलने वाले MCP tools हैं, तो उन्हें Foundry agents से connect करना एक quick win है — आपके custom tools server में कोई code changes किए बिना proper auth के साथ enterprise AI capabilities बन जाते हैं।

हर authentication method के step-by-step निर्देशों के लिए पूरी guide पढ़ें, और production setups के लिए detailed docs देखें।

GitHub Copilot का Modernization Assessment सबसे अच्छा Migration Tool है जिसे आप अभी तक Use नहीं कर रहे

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

एक legacy .NET Framework app को modern .NET पर migrate करना उन कामों में से एक है जो सब जानते हैं करना चाहिए, लेकिन कोई शुरू नहीं करना चाहता। यह कभी सिर्फ “target framework बदलो” नहीं होता। APIs गायब हो गई हैं, packages अब exist नहीं करते, hosting models बिल्कुल अलग तरह से काम करते हैं, और हज़ारों छोटे decisions हैं — क्या containerize करना है, क्या rewrite करना है, और क्या छोड़ना है।

Jeffrey Fritz ने GitHub Copilot के modernization assessment का विस्तृत विश्लेषण publish किया है, और सच में? .NET के लिए यह सबसे अच्छा migration tooling है जो मैंने देखा है। Code generation की वजह से नहीं — वह तो अब baseline है। बल्कि उस assessment document की वजह से जो यह तैयार करता है।

यह सिर्फ Code Suggestion Engine नहीं है

VS Code extension एक Assess → Plan → Execute model follow करता है। Assessment phase आपके पूरे codebase का विश्लेषण करती है और एक structured document तैयार करती है जो सब कुछ capture करती है: क्या बदलने की ज़रूरत है, कौन-से Azure resources provision करने हैं, कौन-सा deployment model उपयोग करना है। Infrastructure-as-code, containerization, deployment manifests — सब कुछ assessment के findings से निकलता है।

Assessment आपके project में .github/modernize/assessment/ के अंतर्गत store होती है। हर run एक independent report तैयार करता है, इसलिए आप एक history बनाते हैं और track कर सकते हैं कि जैसे-जैसे आप issues fix करते हैं आपकी migration posture कैसे evolve होती है।

शुरू करने के दो तरीके

Recommended Assessment — fast path। Curated domains (Java/.NET Upgrade, Cloud Readiness, Security) में से चुनें और configuration को छुए बिना meaningful results प्राप्त करें। यह देखने के लिए excellent है कि आपकी app कहाँ खड़ी है।

Custom Assessment — targeted path। ठीक वही configure करें जो analyze करना है: target compute (App Service, AKS, Container Apps), target OS, containerization analysis। Migration approaches की side-by-side तुलना के लिए multiple Azure targets चुनें।

वह comparison view सच में उपयोगी है। App Service के लिए 3 mandatory issues वाली एक app के लिए AKS पर 7 हो सकती हैं। दोनों देखने से migration path commit करने से पहले hosting decision drive करने में मदद मिलती है।

Issue Breakdown Actionable है

हर issue एक criticality level के साथ आती है:

Mandatory — ठीक करना ज़रूरी है या migration fail होगी
Potential — migration को affect कर सकती है, human judgment ज़रूरी है
Optional — recommended improvements, migration block नहीं करेंगी

और हर issue affected files और line numbers से link करती है, बताती है कि क्या गलत है और आपके target platform के लिए यह क्यों मायने रखता है, concrete remediation steps देती है (सिर्फ “यह ठीक करो” नहीं), और official documentation के links include करती है।

आप individual issues developers को सौंप सकते हैं और उनके पास act करने के लिए सब कुछ है। यही फ़र्क है एक ऐसे tool में जो आपको “एक problem है” बताता है और एक जो आपको बताता है कि इसे कैसे solve करना है।

Covered Upgrade Paths

.NET के लिए specifically:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

हर upgrade path में detection rules हैं जो जानती हैं कि कौन-से APIs हटाए गए, कौन-से patterns का कोई direct equivalent नहीं है, और किन security issues पर ध्यान देना है।

Multiple apps manage करने वाली teams के लिए, एक CLI भी है जो multi-repo batch assessments support करती है — सभी repos clone करें, सभी assess करें, per-app reports और एक aggregated portfolio view प्राप्त करें।

मेरी राय

अगर आप legacy .NET Framework apps पर बैठे हैं (और सच में, ज़्यादातर enterprise teams ऐसी ही हैं), तो यही वह tool है जिससे शुरू करना चाहिए। Assessment document अकेले समय के लायक है — यह एक अस्पष्ट “हमें modernize करना चाहिए” को स्पष्ट, prioritized work items की एक concrete list में बदलता है जिनके आगे बढ़ने के clear paths हैं।

Collaborative workflow भी smart है: assessments export करें, अपनी team के साथ share करें, बिना re-run किए import करें। Architecture reviews जहाँ decision-makers वे नहीं हैं जो tools चला रहे हैं? Covered।

निष्कर्ष

GitHub Copilot का modernization assessment .NET migration को एक डरावने, undefined project से एक structured, trackable process में बदलता है। अपना current status देखने के लिए recommended assessment से शुरू करें, फिर Azure targets की तुलना करने और अपना migration plan बनाने के लिए custom assessments उपयोग करें।

पूरा walkthrough पढ़ें और अपने codebase पर इसे आज़माने के लिए VS Code extension लें।

MCP Apps को Fluent API मिला — .NET में तीन Steps में Rich AI Tool UIs बनाएं

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

MCP tools AI agents को capabilities देने के लिए बेहतरीन हैं। लेकिन क्या होगा अगर आपके tool को user को कुछ दिखाना हो — एक dashboard, एक form, एक interactive visualization? यहीं MCP Apps काम आते हैं, और उन्हें build करना अब बहुत आसान हो गया है।

Azure SDK team की Lilian Kasem ने .NET Azure Functions पर MCP Apps के लिए नया fluent configuration API introduce किया, और यह उस तरह का developer experience improvement है जो आपको सोचने पर मजबूर करता है कि यह हमेशा से इतना simple क्यों नहीं था।

MCP Apps क्या हैं?

MCP Apps Model Context Protocol को extend करते हैं जिससे tools अपने खुद के UI views, static assets, और security controls carry कर सकें। सिर्फ text return करने की बजाय, आपका MCP tool full HTML experiences render कर सकता है — interactive dashboards, data visualizations, configuration forms — सब AI agents द्वारा invokable और MCP clients द्वारा users को present किए जाने योग्य।

पहले की दिक्कत यह थी कि यह सब manually wire करने के लिए MCP spec को गहराई से जानना ज़रूरी था: ui:// URIs, special mime types, tools और resources के बीच metadata coordination। मुश्किल नहीं, लेकिन झंझटी।

Fluent API तीन steps में

Step 1: अपना function define करें। बस एक standard Azure Functions MCP tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Step 2: इसे MCP App में promote करें। अपने program startup में:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Step 3: अपना HTML view जोड़ें। assets/hello-app.html बनाएं जिसमें आपको जो भी UI चाहिए।

बस। Fluent API सारी MCP spec plumbing handle करता है — synthetic resource function generate करना, सही mime type set करना, वह metadata inject करना जो आपके tool को उसके view से connect करता है।

API surface अच्छी तरह design किया गया है

कुछ चीज़ें जो मुझे वाकई पसंद हैं:

View sources flexible हैं। आप disk पर files से HTML serve कर सकते हैं, या self-contained deployments के लिए resources directly अपनी assembly में embed कर सकते हैं:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP composable है। आप explicitly उन origins को allowlist करते हैं जिनकी आपके app को ज़रूरत है, least-privilege principles follow करते हुए। WithCsp को कई बार call करें और origins accumulate होते हैं:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Visibility control। आप किसी tool को केवल LLM को, केवल host UI को, या दोनों को visible बना सकते हैं। एक ऐसा tool चाहते हैं जो सिर्फ UI render करे और model द्वारा call नहीं होना चाहिए? आसान:

.WithVisibility(McpVisibility.App) // UI-only, model से छुपा हुआ

शुरुआत करें

Preview package जोड़ें:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

अगर आप पहले से Azure Functions के साथ MCP tools build कर रहे हैं, तो यह बस एक package update है। MCP Apps quickstart शुरुआत के लिए सबसे अच्छी जगह है।

निष्कर्ष

MCP Apps AI tooling space में सबसे exciting developments में से एक हैं — ऐसे tools जो सिर्फ काम नहीं करते बल्कि users को कुछ दिखा भी सकते हैं। Fluent API protocol की complexity हटाता है और आपको उस पर focus करने देता है जो मायने रखता है: आपके tool की logic और उसका UI।

Complete API reference और examples के लिए पूरी post पढ़ें।

Microsoft Foundry March 2026 — GPT-5.4, Agent Service GA, और वह SDK Refresh जो सब कुछ बदल देता है

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

Monthly “What’s New in Microsoft Foundry” posts आमतौर पर incremental improvements और कभी-कभी एक headline feature का mix होती हैं। March 2026 edition? यह basically सब headline features हैं। Foundry Agent Service GA हो गया, GPT-5.4 production के लिए ship हुआ, SDK का एक major stable release आया, और Fireworks AI Azure पर open model inference लाया। आइए breakdown करें कि .NET developers के लिए क्या मायने रखता है।

Foundry Agent Service production-ready है

यही सबसे बड़ी खबर है। Next-gen agent runtime generally available है — OpenAI Responses API पर बना, OpenAI agents के साथ wire-compatible, और multiple providers के models के लिए open। अगर आप आज Responses API के साथ build कर रहे हैं, तो Foundry पर migrate करने से आपकी existing agent logic के ऊपर enterprise security, private networking, Entra RBAC, full tracing, और evaluation मिलता है।

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Key additions: end-to-end private networking, MCP auth expansion (OAuth passthrough सहित), speech-to-speech agents के लिए Voice Live preview, और 6 नए regions में hosted agents।

GPT-5.4 — raw intelligence से ज़्यादा reliability

GPT-5.4 स्मार्ट होने के बारे में नहीं है। यह ज़्यादा reliable होने के बारे में है। Long interactions पर stronger reasoning, बेहतर instruction adherence, कम mid-workflow failures, और integrated computer use capabilities। Production agents के लिए, वह reliability benchmark scores से कहीं ज़्यादा मायने रखती है।

Model	Pricing (per M tokens)	Best For
GPT-5.4 (≤272K)	$2.50 / $15 output	Production agents, coding, document workflows
GPT-5.4 Pro	$30 / $180 output	Deep analysis, scientific reasoning
GPT-5.4 Mini	Cost-effective	Classification, extraction, lightweight tool calls

Smart approach एक routing strategy है: GPT-5.4 Mini high-volume, low-latency work handle करे जबकि GPT-5.4 reasoning-heavy requests लेता है।

SDK आखिरकार stable है

azure-ai-projects SDK सभी languages में stable releases के साथ ship हुआ — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, और .NET 2.0.0 (April 1)। azure-ai-agents dependency चली गई — सब कुछ AIProjectClient के अंदर रहता है। pip install azure-ai-projects से install करें और package openai और azure-identity को direct dependencies के रूप में bundle करता है।

.NET developers के लिए, इसका मतलब है full Foundry surface के लिए एक single NuGet package। अब अलग-अलग agent SDKs को juggle नहीं करना।

Fireworks AI Azure पर open models लाता है

शायद सबसे architecturally interesting addition: Fireworks AI जो daily 13+ trillion tokens ~180K requests/second पर process करता है, अब Foundry के ज़रिए available है। Launch पर DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, और MiniMax M2.5।

असली कहानी है bring-your-own-weights — serving stack बदले बिना कहीं से भी quantized या fine-tuned weights upload करें। Serverless pay-per-token या provisioned throughput के ज़रिए deploy करें।

अन्य highlights

Phi-4 Reasoning Vision 15B — charts, diagrams, और document layouts के लिए multimodal reasoning
Evaluations GA — Azure Monitor में piped continuous production monitoring के साथ out-of-the-box evaluators
Priority Processing (Preview) — latency-sensitive workloads के लिए dedicated compute lane
Voice Live — speech-to-speech runtime जो directly Foundry agents से connect होता है
Tracing GA — sort और filter के साथ end-to-end agent trace inspection
PromptFlow deprecation — January 2027 तक Microsoft Framework Workflows पर migration

निष्कर्ष

March 2026 Foundry के लिए एक turning point है। Agent Service GA, सभी languages में stable SDKs, reliable production agents के लिए GPT-5.4, और Fireworks AI के ज़रिए open model inference — platform serious workloads के लिए तैयार है।

Full roundup पढ़ें और अपना पहला agent build करें शुरुआत के लिए।

SQL MCP Server — AI एजेंट्स को डेटाबेस एक्सेस देने का सही तरीका

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

सच बात करें तो: आज उपलब्ध अधिकांश database MCP servers डरावने हैं। वे एक natural language query लेते हैं, तुरंत SQL generate करते हैं, और उसे आपके production data पर चला देते हैं। क्या गलत हो सकता है? (सब कुछ। सब कुछ गलत हो सकता है।)

Azure SQL टीम ने अभी SQL MCP Server पेश किया, और यह एक मौलिक रूप से अलग दृष्टिकोण अपनाता है। Data API builder (DAB) 2.0 की एक feature के रूप में बना, यह AI एजेंट्स को database operations तक structured, निर्धारित access देता है — NL2SQL के बिना, आपका schema उजागर किए बिना, और हर कदम पर पूरे RBAC के साथ।

NL2SQL क्यों नहीं?

यह सबसे दिलचस्प design निर्णय है। Models निर्धारित नहीं होते, और complex queries में सूक्ष्म त्रुटियाँ पैदा होने की सबसे अधिक संभावना होती है। जो queries उपयोगकर्ता AI से generate करवाना चाहते हैं, वही non-deterministic तरीके से produce होने पर सबसे अधिक जाँच की माँग करती हैं।

इसके बजाय, SQL MCP Server एक NL2DAB दृष्टिकोण अपनाता है। एजेंट Data API builder की entity abstraction layer और built-in query builder के साथ काम करता है ताकि accurate, well-formed T-SQL निर्धारित रूप से produce की जा सके। उपयोगकर्ता के लिए परिणाम वही रहता है, लेकिन hallucinated JOINs या accidental data exposure का जोखिम नहीं रहता।

सात tools, सात सौ नहीं

SQL MCP Server database के आकार चाहे जो हो, ठीक सात DML tools expose करता है:

describe_entities — उपलब्ध entities और operations खोजें
create_record — rows insert करें
read_records — tables और views query करें
update_record — rows modify करें
delete_record — rows हटाएं
execute_entity — stored procedures चलाएं
aggregate_records — aggregation queries

यह समझदारी है क्योंकि context windows एजेंट की सोचने की जगह हैं। सैकड़ों tool definitions से भर देने पर reasoning के लिए कम जगह बचती है। सात fixed tools एजेंट को navigate करने की बजाय सोचने पर केंद्रित रखते हैं।

प्रत्येक tool को individually enable या disable किया जा सकता है:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

तीन commands में शुरुआत

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

बस, आपका SQL MCP Server आपकी Customers table expose कर के चल पड़ा। Entity abstraction layer का मतलब है कि आप नाम और columns को alias कर सकते हैं, प्रत्येक role के लिए fields सीमित कर सकते हैं, और ठीक वही नियंत्रित कर सकते हैं जो एजेंट देखता है — बिना internal schema की जानकारी उजागर किए।

Security की कहानी पक्की है

यहीं Data API builder की परिपक्वता काम आती है:

हर layer पर RBAC — प्रत्येक entity परिभाषित करती है कि कौन से roles read, create, update, या delete कर सकते हैं, और कौन से fields दिखते हैं
Azure Key Vault integration — connection strings और secrets सुरक्षित रूप से manage होते हैं
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — एजेंट raw SQL के बजाय एक controlled contract के माध्यम से interact करते हैं

Schema abstraction विशेष रूप से महत्वपूर्ण है। आपके internal table और column names एजेंट को कभी नहीं दिखते। आप entities, aliases, और descriptions परिभाषित करते हैं जो AI interaction के लिए उचित हों — आपके database ERD के लिए नहीं।

Multi-database और multi-protocol

SQL MCP Server Microsoft SQL, PostgreSQL, Azure Cosmos DB, और MySQL को support करता है। और क्योंकि यह एक DAB feature है, आपको एक ही configuration से REST, GraphQL, और MCP endpoints एक साथ मिलते हैं। वही entity definitions, वही RBAC rules, वही security — तीनों protocols में।

DAB 2.0 में auto-configuration आपके database को inspect करके dynamically configuration बना सकती है, अगर आप rapid prototyping के लिए कम abstraction से comfortable हैं।

मेरा नजरिया

AI एजेंट्स के लिए enterprise database access इसी तरह काम करनी चाहिए। “अरे LLM, मेरे लिए कुछ SQL लिखो और production पर चला दो” वाला तरीका नहीं। बल्कि: एक well-defined entity layer, deterministic query generation, हर कदम पर RBAC, caching, monitoring, और telemetry। यह सबसे अच्छे अर्थ में उबाऊ है।

.NET डेवलपर्स के लिए, integration की कहानी साफ है — DAB एक .NET tool है, MCP Server एक container के रूप में चलता है, और यह Azure SQL के साथ काम करता है, जिसे हम में से अधिकांश पहले से उपयोग कर रहे हैं। अगर आप ऐसे AI एजेंट्स बना रहे हैं जिन्हें data access चाहिए, तो यहाँ से शुरू करें।

अंतिम बात

SQL MCP Server मुफ्त, open-source है, और कहीं भी चलता है। यह Microsoft की तरफ से AI एजेंट्स को सुरक्षित database access देने का prescriptive तरीका है। शुरुआत करने के लिए पूरी पोस्ट और documentation देखें।

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 देखें।

रियल-टाइम Multi-Agent UIs बनाना जो Black Box की तरह न लगें

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

multi-agent systems के बारे में एक बात यह है: demos में वे बेहद शानदार लगते हैं। तीन agents काम आगे-पीछे भेज रहे हैं, समस्याएँ सुलझा रहे हैं, निर्णय ले रहे हैं। फिर आप इसे असली users के सामने रखने की कोशिश करते हैं और… खामोशी। एक घूमता हुआ indicator। कोई अंदाज़ा नहीं कि कौन-सा agent क्या कर रहा है या सिस्टम क्यों रुका हुआ है। यह कोई product नहीं है — यह एक भरोसे की समस्या है।

Microsoft Agent Framework team ने अभी-अभी MAF workflows को AG-UI के साथ जोड़ने पर एक शानदार walkthrough प्रकाशित किया है। AG-UI एक open protocol है जो Server-Sent Events के ज़रिए agent execution events को frontend पर stream करता है। और सच में? यही वह bridge है जिसकी हमें कमी थी।

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

अगर आप AI-powered apps बना रहे हैं, तो आप शायद इस दीवार से टकरा चुके हैं। आपका backend orchestration बढ़िया काम करता है — agents एक-दूसरे को काम सौंपते हैं, tools चलते हैं, फैसले होते हैं। लेकिन frontend को पर्दे के पीछे क्या हो रहा है, इसका कोई अंदाज़ा नहीं। AG-UI इसे ठीक करता है — यह agent events (जैसे RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) को SSE पर सीधे आपकी UI layer तक stream करने के लिए एक standard protocol परिभाषित करता है।

जो demo उन्होंने बनाया वह तीन agents वाला customer support workflow है: एक triage agent जो requests को route करता है, एक refund agent जो पैसों का काम संभालता है, और एक order agent जो replacements manage करता है। हर agent के अपने tools हैं, और handoff topology स्पष्ट रूप से परिभाषित है — “prompt से खुद समझ लो” वाला कोई झमेला नहीं।

Handoff topology असली सितारा है

जो चीज़ मेरी नज़र में आई वह यह है कि HandoffBuilder आपको agents के बीच एक directed routing graph घोषित करने देता है:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

हर add_handoff एक natural-language description के साथ एक directed edge बनाता है। Framework इस topology के आधार पर हर agent के लिए handoff tools generate करता है। तो routing के फैसले आपकी orchestration structure पर आधारित हैं, न कि LLM की मर्ज़ी पर। production reliability के लिए यह बहुत बड़ी बात है।

Human-in-the-loop जो वाकई काम करता है

Demo में दो interrupt patterns दिखाए गए हैं जो किसी भी real-world agent app को चाहिए:

Tool approval interrupts — जब कोई agent approval_mode="always_require" वाला tool call करता है, तो workflow रुक जाता है और एक event emit होता है। Frontend tool name और arguments के साथ एक approval modal render करता है। कोई token-burning retry loops नहीं — बस एक साफ pause-approve-resume flow।

Information request interrupts — जब किसी agent को user से ज़्यादा context चाहिए (जैसे कोई order ID), तो वह रुकता है और पूछता है। Frontend सवाल दिखाता है, user जवाब देता है, और execution ठीक वहाँ से दोबारा शुरू होती है जहाँ वह रुकी थी।

दोनों patterns standard AG-UI events की तरह stream होते हैं, इसलिए आपके frontend को हर agent के लिए custom logic की ज़रूरत नहीं — वह बस SSE connection से आने वाला event render करता है।

Wiring up करना हैरानी की हद तक आसान है

MAF और AG-UI के बीच integration एक single function call है:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory हर thread के लिए एक fresh workflow बनाता है, इसलिए हर conversation को isolated state मिलती है। Endpoint सारी SSE plumbing अपने आप handle करता है। अगर आप पहले से FastAPI use कर रहे हैं (या इसे एक lightweight layer के रूप में जोड़ सकते हैं), तो यह लगभग zero friction है।

मेरी राय

हम .NET developers के लिए तुरंत यह सवाल उठता है: “क्या मैं यह C# में कर सकता हूँ?” Agent Framework .NET और Python दोनों के लिए उपलब्ध है, और AG-UI protocol language-agnostic है (यह बस SSE है)। तो यह specific demo Python और FastAPI use करता है, लेकिन pattern सीधे translate होता है। आप same AG-UI event schema का पालन करते हुए SSE endpoints के साथ एक ASP.NET Core minimal API wire up कर सकते हैं।

बड़ी बात यह है कि multi-agent UIs एक first-class concern बनती जा रही हैं, afterthought नहीं। अगर आप कुछ ऐसा बना रहे हैं जहाँ agents humans के साथ interact करते हैं — customer support, approval workflows, document processing — तो MAF orchestration और AG-UI transparency का यह combination वह pattern है जिसे follow करना चाहिए।

Wrapping up

AG-UI + Microsoft Agent Framework आपको दोनों दुनियाओं का सर्वश्रेष्ठ देता है: backend पर robust multi-agent orchestration और frontend पर real-time visibility। Black-box agent interactions अब नहीं।

और गहराई से जानने के लिए full walkthrough और AG-UI protocol repo देखें।

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 देखें।

C# 15 में Union Types आ गए — और वे बिल्कुल वैसे ही हैं जैसा हम माँग रहे थे

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

यही वह feature है जिसका मैं इंतज़ार कर रहा था। C# 15 में union keyword पेश किया गया है — उचित discriminated unions जिनमें compiler-enforced exhaustive pattern matching है। अगर आपने कभी F# के discriminated unions या Rust के enums से ईर्ष्या की है, तो आप जानते हैं कि यह क्यों मायने रखता है।

Bill Wagner ने .NET blog पर इसका विस्तृत विश्लेषण publish किया है, और सच में? Design clean, practical, और बिल्कुल C# style का है। आइए मैं आपको बताता हूँ कि यहाँ वास्तव में क्या है और यह पहली नज़र में जितना लगता है उससे बड़ी बात क्यों है।

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

C# 15 से पहले, किसी method से “कई possible types में से एक” return करना हमेशा एक compromise था:

object — कोई constraints नहीं, कोई compiler help नहीं, हर जगह defensive casting
Marker interfaces — बेहतर, लेकिन कोई भी उन्हें implement कर सकता है। Compiler कभी set को complete नहीं मान सकता
Abstract base classes — वही समस्या, साथ ही types को एक common ancestor की ज़रूरत है

इनमें से कोई भी आपको वह नहीं देता जो आप वास्तव में चाहते हैं: types का एक closed set जहाँ compiler guarantee करता है कि आपने हर case handle किया है। Union types यही करते हैं।

Syntax खूबसूरती से सरल है

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

एक line। Pet एक Cat, एक Dog, या एक Bird hold कर सकता है। Implicit conversions automatically generate होती हैं:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

और यहाँ जादू है — compiler exhaustive matching enforce करता है:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

_ discard की ज़रूरत नहीं। Compiler जानता है कि यह switch हर possible case cover करता है। अगर आप बाद में union में चौथा type जोड़ते हैं, तो हर switch expression जो उसे handle नहीं करती warning produce करती है। Missing cases build time पर पकड़ी जाती हैं, runtime पर नहीं।

यह व्यावहारिक रूप से कहाँ काम आता है

Pet का उदाहरण प्यारा है, लेकिन real code में unions वास्तव में कहाँ चमकते हैं यह देखें।

API responses जो अलग-अलग shapes return करती हैं

public union ApiResult<T>(T, ApiError, ValidationFailure);

अब हर consumer को success, error, और validation failure handle करने पर मजबूर किया जाता है। “मैं error case check करना भूल गया” bugs नहीं।

Single value या collection

OneOrMore<T> pattern दिखाता है कि unions में helper methods के साथ एक body कैसे हो सकती है:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Callers जो भी form सुविधाजनक हो वह pass करते हैं:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

असंबंधित types को Compose करना

यह traditional hierarchies पर killer feature है। आप ऐसे types को union कर सकते हैं जिनमें कुछ भी common नहीं है — string और Exception, int और IEnumerable<T>। कोई common ancestor ज़रूरी नहीं।

मौजूदा Libraries के लिए Custom Unions

यहाँ एक smart design choice है: कोई भी class या struct जिसमें [Union] attribute हो, उसे union type के रूप में पहचाना जाता है, जब तक वह basic pattern follow करे (case types के लिए public constructors और एक Value property)। OneOf जैसी libraries जो पहले से union-like types provide करती हैं, वे अपनी internals rewrite किए बिना compiler support में opt in कर सकती हैं।

Value types के साथ performance-sensitive scenarios के लिए, libraries HasValue और TryGetValue methods के साथ एक non-boxing access pattern implement कर सकती हैं।

बड़ी तस्वीर

Union types C# में आने वाली एक broader exhaustiveness story का हिस्सा हैं:

Union types — types के closed set पर exhaustive matching (अभी preview में available)
Closed hierarchies — closed modifier defining assembly के बाहर derived classes को रोकता है (proposed)
Closed enums — declared members के अलावा values बनाने से रोकता है (proposed)

साथ में, ये तीन features C# को किसी भी mainstream language में सबसे comprehensive type-safe pattern matching systems में से एक देंगे।

आज ही आज़माएँ

Union types .NET 11 Preview 2 में available हैं:

.NET 11 Preview SDK install करें
अपने project में net11.0 target करें
<LangVersion>preview</LangVersion> set करें

एक caveat: Preview 2 में, आपको अपने project में UnionAttribute और IUnion declare करने होंगे क्योंकि वे अभी runtime में नहीं हैं। Docs repo से RuntimePolyfill.cs लें, या यह add करें:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

निष्कर्ष

Union types उन features में से हैं जो आपको सोचने पर मजबूर करते हैं कि इनके बिना हम कैसे काम करते थे। Compiler-enforced exhaustive matching, clean syntax, generic support, और मौजूदा pattern matching के साथ integration — यह सब कुछ है जो हम माँग रहे थे, C# के style में।

.NET 11 Preview 2 में इन्हें आज़माएँ, चीज़ें तोड़ें, और GitHub पर अपना feedback share करें। यह preview है, और C# team सक्रिय रूप से सुन रही है। आपके edge cases और design feedback final release को आकार देंगे।

पूर्ण language reference के लिए, union types docs और feature specification देखें।

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।

Microsoft Agent Framework 1.0 पर पहुँचा — .NET Developers के लिए असल में क्या मायने रखता है

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

अगर आप Agent Framework की यात्रा को Semantic Kernel और AutoGen के शुरुआती दिनों से follow कर रहे हैं, तो यह milestone महत्वपूर्ण है। Microsoft Agent Framework ने अभी-अभी version 1.0 हासिल किया है — production-ready, stable APIs, long-term support का वादा। यह .NET और Python दोनों के लिए उपलब्ध है, और वाकई real workloads के लिए तैयार है।

घोषणा के शोर को काटकर, अगर आप .NET के साथ AI-powered apps बना रहे हैं तो जो मायने रखता है उस पर ध्यान देते हैं।

संक्षिप्त में

Agent Framework 1.0 जो पहले Semantic Kernel और AutoGen थे उन्हें एक single, open-source SDK में एकत्रित करता है। एक agent abstraction। एक orchestration engine। कई AI providers। अगर आप enterprise patterns के लिए Semantic Kernel और research-grade multi-agent workflows के लिए AutoGen के बीच झूलते रहे हैं, तो अब रुकिए। यही एक SDK है।

शुरुआत करना लगभग आसान है

.NET में एक working agent यह रहा:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

बस इतना। कुछ lines और आपके पास Azure Foundry के विरुद्ध एक AI agent चल रहा है। Python का equivalent उतना ही संक्षिप्त है। जैसे-जैसे आगे बढ़ें, function tools, multi-turn conversations, और streaming जोड़ें — API surface बड़ा होता जाता है लेकिन अजीब नहीं।

Multi-agent orchestration — यह असली चीज़ है

Single agents demos के लिए ठीक हैं, लेकिन production scenarios में अक्सर coordination की ज़रूरत होती है। Agent Framework 1.0 Microsoft Research और AutoGen से सीधे battle-tested orchestration patterns लेकर आता है:

Sequential — agents क्रम में process करते हैं (writer → reviewer → editor)
Concurrent — कई agents को parallel में fan out करें, results converge करें
Handoff — एक agent intent के आधार पर दूसरे को delegate करता है
Group chat — कई agents discuss करते हैं और solution पर converge होते हैं
Magentic-One — MSR का research-grade multi-agent pattern

सभी streaming, checkpointing, human-in-the-loop approvals, और pause/resume support करते हैं। Checkpointing हिस्सा बेहद ज़रूरी है — long-running workflows process restarts के बाद भी survive करते हैं। हम .NET developers के लिए जिन्होंने Azure Functions के साथ durable workflows बनाए हैं, यह जाना-पहचाना लगता है।

सबसे ज़्यादा मायने रखने वाले features

जो जानने लायक है उसकी मेरी shortlist:

Middleware hooks। आप जानते हैं कैसे ASP.NET Core में middleware pipelines होती हैं? वही concept, लेकिन agent execution के लिए। हर stage को intercept करें — agent prompts को छुए बिना content safety, logging, compliance policies जोड़ें। यही तरीका है agents को enterprise-ready बनाने का।

Pluggable memory। Conversational history, persistent key-value state, vector-based retrieval। अपना backend चुनें: Foundry Agent Service, Mem0, Redis, Neo4j, या खुद का बनाएँ। Memory ही एक stateless LLM call को ऐसे agent में बदलती है जो वाकई context याद रखता है।

Declarative YAML agents। अपने agent की instructions, tools, memory, और orchestration topology को version-controlled YAML files में define करें। Single API call से load और run करें। जो teams बिना code redeploy किए agent behavior पर iterate करना चाहती हैं, उनके लिए यह game-changer है।

A2A और MCP support। MCP (Model Context Protocol) agents को dynamically external tools discover और invoke करने देता है। A2A (Agent-to-Agent protocol) cross-runtime collaboration सक्षम करता है — आपके .NET agents दूसरे frameworks में चल रहे agents के साथ coordinate कर सकते हैं। A2A 1.0 support जल्द आ रहा है।

देखने लायक preview features

1.0 में कुछ features preview के रूप में ship हुए हैं — functional हैं लेकिन APIs बदल सकती हैं:

DevUI — agent execution, message flows, और tool calls को real time में visualize करने के लिए browser-based local debugger। Application Insights की तरह समझें, लेकिन agent reasoning के लिए।
GitHub Copilot SDK और Claude Code SDK — अपने orchestration code से सीधे Copilot या Claude को agent harness के रूप में use करें। एक coding-capable agent को उसी workflow में अपने दूसरे agents के साथ compose करें।
Agent Harness — agents को shell, file system, और messaging loops तक access देने वाला customizable local runtime। Coding agents और automation patterns सोचें।
Skills — reusable domain capability packages जो agents को out of the box structured capabilities देते हैं।

Semantic Kernel या AutoGen से migrate करना

अगर आपके पास existing Semantic Kernel या AutoGen code है, तो dedicated migration assistants हैं जो आपका code analyze करते हैं और step-by-step migration plans generate करते हैं। Semantic Kernel migration guide और AutoGen migration guide सब कुछ walk through करते हैं।

अगर आप RC packages पर हैं, तो 1.0 में upgrade करना बस एक version bump है।

Wrapping up

Agent Framework 1.0 वह production milestone है जिसका enterprise teams को इंतज़ार था। Stable APIs, multi-provider support, orchestration patterns जो scale पर वाकई काम करते हैं, और Semantic Kernel और AutoGen दोनों से migration paths।

Framework GitHub पर पूरी तरह open source है, और आप आज ही dotnet add package Microsoft.Agents.AI से शुरुआत कर सकते हैं। हाथ गंदे करने के लिए quickstart guide और samples देखें।

अगर आप “production में use करना safe है” का signal ढूंढ रहे थे — यह रहा।

Aspire 13.2 के Dashboard को मिला Telemetry API — और इसने सब कुछ बदल दिया

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

अगर आप .NET Aspire के साथ distributed apps बना रहे हैं, तो आप पहले से जानते हैं कि dashboard पूरे experience की सबसे अच्छी चीज़ है। आपके सारे traces, logs और metrics एक जगह — कोई external Jaeger नहीं, कोई Seq setup नहीं, कोई “let me check the other terminal” के moments नहीं।

Aspire 13.2 ने इसे काफी बेहतर बना दिया है। James Newton-King ने update की घोषणा की, और सच कहूँ तो? Telemetry export और API features अकेले ही upgrade के लायक हैं।

Telemetry export अब एक समझदार तरीके से

यहाँ वो scenario है जो हम सभी ने झेला है: आप एक distributed issue debug कर रहे हैं, बीस मिनट की setup के बाद आखिरकार इसे reproduce करते हैं, और अब आपको अपनी team के साथ share करना है कि क्या हुआ। पहले? Screenshots। Trace IDs copy-paste करना। वही पुरानी गड़बड़।

Aspire 13.2 में एक proper Manage logs and telemetry dialog जुड़ा है जहाँ आप कर सकते हैं:

सारी telemetry clear करना (repro attempt से पहले उपयोगी)
Selected telemetry को standard OTLP/JSON format में ZIP file में export करना
उस ZIP को किसी भी Aspire dashboard में बाद में re-import करना

वह आखिरी हिस्सा killer feature है। आप एक bug reproduce करते हैं, telemetry export करते हैं, इसे अपने work item में attach करते हैं, और आपका teammate इसे अपने dashboard में import कर सकता है ताकि ठीक वही देख सके जो आपने देखा। अब “क्या आप इसे अपनी machine पर reproduce कर सकते हैं?” नहीं पूछना पड़ेगा।

Individual traces, spans और logs को भी उनके context menus में “Export JSON” का option मिलता है। एक specific trace share करनी है? Right-click, JSON copy करें, PR description में paste करें। हो गया।

Telemetry API असली game changer है

यही वो चीज़ है जिसके बारे में मैं सबसे ज़्यादा excited हूँ। Dashboard अब telemetry data को programmatically query करने के लिए /api/telemetry के नीचे एक HTTP API expose करता है। Available endpoints:

GET /api/telemetry/resources — telemetry वाले resources की list
GET /api/telemetry/spans — filters के साथ spans query करें
GET /api/telemetry/logs — filters के साथ logs query करें
GET /api/telemetry/traces — traces की list
GET /api/telemetry/traces/{traceId} — एक specific trace के सभी spans पाएं

सब कुछ OTLP JSON format में वापस आता है। यह नए aspire agent mcp और aspire otel CLI commands को power करता है, लेकिन असली implication बड़ा है: अब आप tooling, scripts और AI agent integrations बना सकते हैं जो आपके app की telemetry को directly query करें।

सोचिए एक AI coding agent जो debugging के दौरान आपके actual distributed traces देख सके। यह अब hypothetical नहीं है — यह वही है जो यह API enable करता है।

GenAI telemetry practical हो गई

अगर आप Semantic Kernel या Microsoft.Extensions.AI के साथ AI-powered apps बना रहे हैं, तो आप improved GenAI telemetry visualizer की सराहना करेंगे। Aspire 13.2 में जुड़ा:

AI tool descriptions Markdown के रूप में rendered
Traces page पर quick AI trace access के लिए एक dedicated GenAI button
Truncated या non-standard GenAI JSON के लिए बेहतर error handling
Tool definitions के बीच click-to-highlight navigation

Blog post में बताया गया है कि VS Code Copilot chat, Copilot CLI, और OpenCode सभी OTEL_EXPORTER_OTLP_ENDPOINT configure करने का support करते हैं। उन्हें Aspire dashboard पर point करें और आप literally telemetry के ज़रिए real time में अपने AI agents की सोच देख सकते हैं। यह एक debugging experience है जो आपको और कहीं नहीं मिलेगी।

अंत में

Aspire 13.2 dashboard को “nice debugging UI” से “programmable observability platform” बना देता है। Export/import workflow अकेले ही distributed debugging में real time बचाता है, और telemetry API AI-assisted diagnostics का दरवाज़ा खोलता है।

अगर आप पहले से Aspire पर हैं, upgrade करें। अगर नहीं हैं — यह aspire.dev देखने का एक अच्छा कारण है और समझने का कि इतना शोर क्यों है।

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 करें।

KubeCon Europe 2026: .NET Developers को वास्तव में क्या जानना चाहिए

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

आप उस feeling को जानते हैं जब एक massive announcement post आती है और आप उसे scroll करते हुए सोच रहे होते हैं “cool, लेकिन यह actually मेरे लिए क्या बदलता है”? हर KubeCon season मेरे साथ यही होता है।

Microsoft ने अभी अपना पूरा KubeCon Europe 2026 roundup publish किया — Brendan Burns द्वारा लिखा गया — और सच में? यहाँ real substance है। सिर्फ feature checkboxes नहीं, बल्कि उस तरह के operational improvements जो बदलते हैं कि आप production में चीज़ें कैसे चलाते हैं।

आइए breakdown करें कि हम .NET developers के लिए क्या मायने रखता है।

service mesh overhead के बिना mTLS

Service meshes के बारे में बात यह है: सभी security guarantees चाहते हैं, कोई operational overhead नहीं चाहता। AKS आखिरकार उस gap को बंद कर रहा है।

Azure Kubernetes Application Network आपको mutual TLS, application-aware authorization, और traffic telemetry देता है — बिना full sidecar-heavy mesh deploy किए। Advanced Container Networking Services में Cilium mTLS के साथ combined, आपको X.509 certificates और identity management के लिए SPIRE का उपयोग करके encrypted pod-to-pod communication मिलती है।

व्यवहार में इसका मतलब: आपके ASP.NET Core APIs background workers से बात कर रहे हों, आपके gRPC services एक-दूसरे को call कर रहे हों — सब network level पर encrypted और identity-verified, zero application code changes के साथ। यह बहुत बड़ी बात है।

ingress-nginx से migrate करने वाली teams के लिए, Application Routing with Meshless Istio भी है जिसमें full Kubernetes Gateway API support है। कोई sidecars नहीं। Standards-based। और उन्होंने incremental migration के लिए ingress2gateway tooling ship की।

GPU observability जो afterthought नहीं है

अगर आप अपनी .NET services के साथ AI inference चला रहे हैं (और honestly, कौन शुरू नहीं कर रहा?), तो आपने शायद GPU monitoring blind spot देखा होगा। आपको CPU/memory के लिए बेहतरीन dashboards मिलते थे और फिर… manual exporter plumbing के बिना GPUs के लिए कुछ नहीं।

AKS अब GPU metrics को natively managed Prometheus और Grafana में expose करता है। वही stack, वही dashboards, वही alerting pipeline। कोई custom exporters नहीं, कोई third-party agents नहीं।

Network side पर, उन्होंने HTTP, gRPC, और Kafka traffic के लिए per-flow visibility one-click Azure Monitor experience के साथ जोड़ी। IPs, ports, workloads, flow direction, policy decisions — सब built-in dashboards में।

और यहाँ वह है जिसने मुझे double-take कराया: agentic container networking एक web UI जोड़ता है जहाँ आप अपने cluster की network state के बारे में natural-language questions पूछ सकते हैं। “Pod X service Y तक क्यों नहीं पहुँच रहा?” → live telemetry से read-only diagnostics। रात 2 बजे यह genuinely useful है।

Cross-cluster networking जिसके लिए PhD नहीं चाहिए

Multi-cluster Kubernetes historically एक “अपना networking glue लाओ” experience रहा है। Azure Kubernetes Fleet Manager अब managed Cilium cluster mesh के ज़रिए cross-cluster networking ship करता है:

AKS clusters में unified connectivity
Cross-cluster discovery के लिए global service registry
Configuration centrally managed, हर cluster पर repeat नहीं

अगर आप resilience या compliance के लिए regions में .NET microservices चला रहे हैं, तो यह बहुत सारी fragile custom plumbing की जगह लेता है। West Europe में Service A, East US में Service B को mesh के ज़रिए discover और call कर सकती है, consistent routing और security policies के साथ।

Upgrades जिनके लिए हिम्मत की ज़रूरत नहीं

सच कहें — production में Kubernetes upgrades stressful होते हैं। “Upgrade और उम्मीद करो” बहुत teams के लिए de facto strategy रही है, और यही मुख्य कारण है कि clusters version पर पिछड़ जाते हैं।

दो नई capabilities इसे बदलती हैं:

Blue-green agent pool upgrades नए configuration के साथ एक parallel node pool बनाते हैं। Behavior validate करें, traffic gradually shift करें, और एक clean rollback path रखें। Production nodes पर in-place mutations नहीं।

Agent pool rollback आपको upgrade बिगड़ने के बाद एक node pool को उसके पिछले Kubernetes version और node image पर revert करने देता है — cluster rebuild किए बिना।

साथ में, ये operators को upgrade lifecycle पर real control देते हैं। .NET teams के लिए, यह मायने रखता है क्योंकि platform velocity directly नियंत्रित करती है कि आप नए runtimes, security patches, और networking capabilities कितनी जल्दी adopt कर सकते हैं।

AI workloads Kubernetes के first-class citizens बन रहे हैं

Upstream open-source work equally important है। Dynamic Resource Allocation (DRA) Kubernetes 1.36 में GA हो गया, जो GPU scheduling को एक proper first-class feature बनाता है बजाय workaround के।

कुछ projects जो देखने लायक हैं:

Project	क्या करता है
AI Runway	Inference के लिए common Kubernetes API — K8s जाने बिना models deploy करें, HuggingFace discovery और cost estimates के साथ
HolmesGPT	Cloud-native के लिए agentic troubleshooting — अब CNCF Sandbox project
Dalec	SBOM generation के साथ declarative container image builds — build stage पर कम CVEs

दिशा स्पष्ट है: आपकी .NET API, आपकी Semantic Kernel orchestration layer, और आपके inference workloads सभी एक consistent platform model पर चलने चाहिए। हम वहाँ पहुँच रहे हैं।

इस हफ्ते मैं कहाँ से शुरू करूँगा

अगर आप अपनी team के लिए इन changes का मूल्यांकन कर रहे हैं, तो यहाँ मेरी honest priority list है:

Observability पहले — non-prod cluster में GPU metrics और network flow logs enable करें। देखें आप क्या miss कर रहे थे।
Blue-green upgrades आज़माएं — अपने अगले production cluster upgrade से पहले rollback workflow test करें। Process में confidence बनाएं।
Identity-aware networking pilot करें — एक internal service path चुनें और Cilium के साथ mTLS enable करें। Overhead measure करें (spoiler: यह minimal है)।
Fleet Manager evaluate करें — अगर आप दो से अधिक clusters चलाते हैं, तो cross-cluster networking reduced custom glue में खुद की cost justify कर देता है।

छोटे experiments, fast feedback। यही हमेशा सही move है।

निष्कर्ष

KubeCon announcements overwhelming हो सकती हैं, लेकिन यह batch genuinely AKS पर .NET teams के लिए needle move करती है। Mesh overhead के बिना बेहतर networking security, real GPU observability, safer upgrades, और मज़बूत AI infrastructure foundations।

अगर आप पहले से AKS पर हैं, तो यह आपका operational baseline tight करने का एक बढ़िया मौका है। और अगर आप .NET workloads को Kubernetes पर move करने की planning कर रहे हैं — platform अभी-अभी काफी ज़्यादा production-ready हो गया है।

SQL MCP Server, SSMS में Copilot, और AI Agents के साथ Database Hub: SQLCon 2026 की असली ज़रूरी बातें

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft ने अभी SQLCon 2026 को FabCon के साथ Atlanta में शुरू किया, और इसमें काफी कुछ है जिसे समझना ज़रूरी है। मूल घोषणा में savings plans से लेकर enterprise compliance features तक सब कुछ शामिल है। मैं enterprise pricing की slides को छोड़ रहा हूँ और उन बातों पर ध्यान केंद्रित कर रहा हूँ जो एक developer के लिए Azure SQL और AI के साथ कुछ बनाते समय वास्तव में मायने रखती हैं।

SQL MCP Server public preview में है

यह मेरे लिए सबसे बड़ी खबर है। Azure SQL Database Hyperscale में अब SQL MCP Server public preview में उपलब्ध है, जो आपको Model Context Protocol का उपयोग करके अपने SQL डेटा को AI agents और Copilots से सुरक्षित रूप से जोड़ने की सुविधा देता है।

अगर आप MCP की लहर को फॉलो कर रहे हैं — और सच कहूँ तो, इसे नज़रअंदाज़ करना अभी मुश्किल है — तो यह एक बड़ी बात है। अपने AI agents को database का context देने के लिए custom data pipelines बनाने की बजाय, आपको SQL डेटा को सीधे expose करने के लिए एक standardized protocol मिलता है। आपके agents live database की जानकारी को query कर सकते हैं, उस पर reasoning कर सकते हैं और action ले सकते हैं।

जो लोग Semantic Kernel या Microsoft Agent Framework के साथ AI agents बना रहे हैं, उनके लिए यह एक clean integration path खोलता है। आपके agent को inventory चेक करनी है? कोई customer record देखना है? किसी order को validate करना है? MCP इसके लिए एक structured तरीका देता है, बिना हर scenario के लिए bespoke data-fetching code लिखे।

SSMS 22 में GitHub Copilot अब GA है

अगर आप SQL Server Management Studio में समय बिताते हैं — और सच कहूँ तो, हम में से अधिकतर अभी भी करते हैं — तो GitHub Copilot अब SSMS 22 में generally available है। वही Copilot experience जो आप VS Code और Visual Studio में पहले से उपयोग करते हैं, लेकिन T-SQL के लिए।

यहाँ व्यावहारिक मूल्य सीधा है: queries लिखने, stored procedures को refactor करने, performance issues को troubleshoot करने और admin tasks संभालने के लिए chat-based assistance। अवधारणा में कुछ क्रांतिकारी नहीं है, लेकिन इसका SSMS में सीधे होना मतलब है कि database काम के लिए AI सहायता पाने के लिए आपको किसी दूसरे editor पर switch नहीं करना पड़ेगा।

Vector indexes को गंभीर upgrade मिला

Azure SQL Database में अब full insert, update, और delete support के साथ तेज़, अधिक capable vector indexes उपलब्ध हैं। इसका मतलब है कि आपका vector डेटा real time में current रहता है — batch reindexing की कोई ज़रूरत नहीं।

नया क्या है:

Quantization — accuracy बहुत कम खोए बिना छोटे index sizes के लिए
Iterative filtering — अधिक precise results के लिए
Query optimizer के साथ गहरा integration — predictable performance के लिए

अगर आप Azure SQL को vector store के रूप में उपयोग करके retrieval-augmented generation (RAG) कर रहे हैं, तो ये improvements सीधे काम आती हैं। आप अपने vectors को उसी database में अपने relational data के साथ रख सकते हैं, जो एक अलग vector database चलाने की तुलना में आपकी architecture को काफी सरल बनाता है।

यही vector enhancements Fabric में SQL database में भी उपलब्ध हैं, क्योंकि दोनों के नीचे एक ही SQL engine चलता है।

Fabric में Database Hub: agentic management

यह थोड़ा भविष्योन्मुखी है, लेकिन दिलचस्प है। Microsoft ने Database Hub in Microsoft Fabric (early access) की घोषणा की, जो Azure SQL, Cosmos DB, PostgreSQL, MySQL और Arc के ज़रिए SQL Server पर एक single pane of glass देता है।

दिलचस्प पहलू सिर्फ unified view नहीं है — यह management का agentic approach है। AI agents लगातार आपके database estate को monitor करते हैं, बताते हैं क्या बदला, समझाते हैं क्यों यह मायने रखता है, और सुझाव देते हैं कि आगे क्या करना है। यह एक human-in-the-loop model है जहाँ agent सारी मेहनत करता है और आप निर्णय लेते हैं।

कई databases manage करने वाली teams के लिए, यह operational noise को वास्तव में कम कर सकता है। Portals के बीच jump करने और manually metrics चेक करने की बजाय, agent signal को आपके पास लाता है।

.NET developers के लिए इसका क्या मतलब है

इन सभी घोषणाओं को जोड़ने वाला धागा स्पष्ट है: Microsoft database stack की हर layer में AI agents को embed कर रहा है। एक gimmick के रूप में नहीं, बल्कि एक practical tooling layer के रूप में।

अगर आप Azure SQL से backed .NET apps बना रहे हैं, तो मैं वास्तव में यही करूँगा:

SQL MCP Server आज़माएं अगर आप AI agents बना रहे हैं। यह आपके agents को database access देने का सबसे clean तरीका है बिना custom plumbing के।
SSMS में Copilot enable करें अगर आपने अभी तक नहीं किया — daily SQL काम के लिए free productivity win।
Vector indexes में देखें अगर आप RAG कर रहे हैं और वर्तमान में एक अलग vector store चला रहे हैं। Azure SQL पर consolidate करने का मतलब है एक कम service manage करना।

अंत में

पूरी announcement में और भी है — savings plans, migration assistants, compliance features — लेकिन developer की कहानी MCP Server, vector improvements और agentic management layer में है। ये वो pieces हैं जो आपके बनाने के तरीके को बदलते हैं, न कि सिर्फ आपके budget को।

पूरी तस्वीर के लिए Shireesh Thota की पूरी announcement देखें, और नया management experience आज़माने के लिए Database Hub early access के लिए sign up करें।

Azure DevOps MCP Server Microsoft Foundry में आया: आपके AI Agents के लिए इसका क्या मतलब है

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

MCP (Model Context Protocol) इन दिनों बहुत चर्चा में है। अगर आप AI agent ecosystem को follow कर रहे हैं, तो आपने शायद देखा होगा कि MCP servers हर जगह दिखने लगे हैं — agents को एक मानकीकृत protocol के ज़रिए बाहरी tools और services के साथ interact करने की क्षमता देते हैं।

अब Azure DevOps MCP Server Microsoft Foundry में उपलब्ध है, और यह उन integrations में से एक है जो आपको व्यावहारिक संभावनाओं के बारे में सोचने पर मजबूर करती है।

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

Microsoft ने Azure DevOps MCP Server को public preview के रूप में पहले ही release किया था — वह MCP server ही है। नया यह है कि Foundry integration आई है। अब आप अपने Foundry agents में tool catalog से सीधे Azure DevOps MCP Server जोड़ सकते हैं।

जो Foundry से परिचित नहीं हैं उनके लिए: यह Microsoft का unified platform है जो बड़े पैमाने पर AI-powered applications और agents बनाने और manage करने के लिए है। Model access, orchestration, evaluation, deployment — सब एक ही जगह।

इसे Setup करना

Setup करना आश्चर्यजनक रूप से सीधा है:

अपने Foundry agent में जाएं Add Tools > Catalog
“Azure DevOps” खोजें
Azure DevOps MCP Server (preview) चुनें और Create पर क्लिक करें
अपना organization नाम डालें और connect करें

बस इतना। आपके agent को अब Azure DevOps tools तक access मिल गई।

आप अपने agent की access को control कर सकते हैं

यहाँ वो हिस्सा है जो मुझे पसंद आया: आप all-or-nothing approach तक सीमित नहीं हैं। आप specify कर सकते हैं कि आपके agent के लिए कौन से tools उपलब्ध हों। तो अगर आप चाहते हैं कि वो केवल work items पढ़े लेकिन pipelines को न छुए, तो आप उसे configure कर सकते हैं। Principle of least privilege, अपने AI agents पर लागू।

यह enterprise scenarios के लिए मायने रखता है जहाँ आप नहीं चाहते कि एक agent गलती से deployment pipeline trigger कर दे क्योंकि किसी ने उससे “release में मदद करो” कहा।

.NET teams के लिए यह क्यों दिलचस्प है

सोचिए यह व्यवहार में क्या enable करता है:

Sprint planning assistants — agents जो work items pull कर सकते हैं, velocity data analyze कर सकते हैं, और sprint capacity suggest कर सकते हैं
Code review bots — agents जो आपके PR context को समझते हैं क्योंकि वे वास्तव में आपके repos और linked work items पढ़ सकते हैं
Incident response — agents जो work items create कर सकते हैं, recent deployments query कर सकते हैं, और bugs को recent changes से correlate कर सकते हैं
Developer onboarding — “मुझे किस पर काम करना चाहिए?” का जवाब actual project data पर आधारित होगा

जो .NET teams पहले से CI/CD pipelines और project management के लिए Azure DevOps use कर रही हैं, उनके लिए एक AI agent का सीधे उन systems के साथ interact करना useful automation की दिशा में एक महत्वपूर्ण कदम है।

बड़ी MCP तस्वीर

यह एक बड़े trend का हिस्सा है: MCP servers AI agents के बाहरी दुनिया से interact करने का मानक तरीका बनते जा रहे हैं। हम GitHub, Azure DevOps, databases, SaaS APIs — सब के लिए MCP servers देख रहे हैं — और Foundry वह hub बनता जा रहा है जहाँ ये सभी connections एक साथ आते हैं।

अगर आप .NET ecosystem में agents बना रहे हैं, तो MCP पर ध्यान देना ज़रूरी है। Protocol मानकीकृत है, tooling mature हो रहा है, और Foundry integration इसे manually server connections wire किए बिना accessible बनाती है।

निष्कर्ष

Foundry में Azure DevOps MCP Server preview में है, इसलिए यह evolve होता रहेगा। लेकिन core workflow solid है: connect करें, tool access configure करें, और अपने agents को आपके DevOps data के साथ काम करने दें। अगर आप पहले से Foundry ecosystem में हैं, तो यह कुछ clicks की दूरी पर है। इसे try करें और देखें कि आप कौन से workflows बना सकते हैं।

पूरी setup और अधिक जानकारी के लिए official announcement देखें।

Foundry Agent Service GA हो गया: .NET Agent Builders के लिए वास्तव में क्या मायने रखता है

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

सच कहें तो — एक AI agent का prototype बनाना सबसे आसान हिस्सा है। मुश्किल हिस्सा है उसके बाद का सब कुछ: इसे production में ले जाना उचित network isolation के साथ, ऐसे evaluations चलाना जिनका वास्तव में कुछ मतलब हो, compliance की आवश्यकताओं को संभालना, और रात 2 बजे चीज़ें तोड़ने से बचना।

Foundry Agent Service अभी GA हो गया है, और यह release उस “सब कुछ बाद में” की खाई को पाटने पर केंद्रित है।

Responses API पर निर्मित

मुख्य बात यह है: next-gen Foundry Agent Service OpenAI Responses API पर बनाया गया है। अगर आप पहले से उस wire protocol के साथ build कर रहे हैं, तो Foundry पर migrate करने के लिए न्यूनतम code बदलाव की ज़रूरत है। आपको मिलेगा: enterprise security, private networking, Entra RBAC, full tracing, और evaluation — आपके existing agent logic के ऊपर।

Architecture जानबूझकर open है। आप किसी एक model provider या एक orchestration framework से locked नहीं हैं। Planning के लिए DeepSeek, generation के लिए OpenAI, orchestration के लिए LangGraph इस्तेमाल करें — runtime consistency layer को संभालता है।

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Private networking: enterprise की बाधा दूर हुई

यह वह feature है जो enterprise adoption को unblock करता है। Foundry अब BYO VNet के साथ पूर्ण end-to-end private networking सपोर्ट करता है:

कोई public egress नहीं — agent traffic कभी public internet से नहीं गुज़रता
Container/subnet injection आपके network में local communication के लिए
Tool connectivity शामिल — MCP servers, Azure AI Search, Fabric data agents सभी private paths पर काम करते हैं

आखिरी बात critical है। सिर्फ inference calls ही private नहीं रहती — हर tool invocation और retrieval call भी आपकी network boundary के अंदर रहती है। उन teams के लिए जो data classification policies के तहत काम करती हैं जो external routing को prohibit करती हैं, यही वह था जो missing था।

MCP authentication सही तरीके से

MCP server connections अब auth patterns का पूरा spectrum सपोर्ट करते हैं:

Auth method	कब उपयोग करें
Key-based	org-wide internal tools के लिए simple shared access
Entra Agent Identity	Service-to-service; agent खुद को authenticate करता है
Entra Managed Identity	Per-project isolation; कोई credential management नहीं
OAuth Identity Passthrough	User-delegated access; agent users की तरफ से काम करता है

OAuth Identity Passthrough दिलचस्प है। जब users को किसी agent को अपने personal data तक access देने की ज़रूरत होती है — उनका OneDrive, उनका Salesforce org, एक user-scoped SaaS API — agent उनकी तरफ से standard OAuth flows के साथ काम करता है। कोई shared system identity नहीं जो सबका रूप धारण करे।

Voice Live: बिना plumbing के speech-to-speech

पहले किसी agent में voice जोड़ने का मतलब था STT, LLM, और TTS को आपस में जोड़ना — तीन services, तीन latency hops, तीन billing surfaces, सब हाथ से synchronize किए जाते। Voice Live इसे एक single managed API में समेट देता है जिसमें:

Semantic voice activity और end-of-turn detection (सिर्फ silence नहीं, meaning समझता है)
Server-side noise suppression और echo cancellation
Barge-in support (users mid-response interrupt कर सकते हैं)

Voice interactions उसी agent runtime से गुज़रती हैं जो text के लिए है। वही evaluators, वही traces, वही cost visibility। Customer support, field service, या accessibility scenarios के लिए, यह उस custom audio pipeline की जगह लेता है जिसकी पहले ज़रूरत थी।

Evaluations: checkbox से continuous monitoring तक

यहाँ Foundry production quality के बारे में गंभीर हो जाता है। Evaluation system में अब तीन layers हैं:

Out-of-the-box evaluators — coherence, relevance, groundedness, retrieval quality, safety। किसी dataset या live traffic से connect करें और scores वापस पाएं।
Custom evaluators — अपनी business logic, tone standards, और domain-specific compliance rules encode करें।
Continuous evaluation — Foundry live production traffic sample करता है, आपका evaluator suite चलाता है, और dashboards के ज़रिए results सामने लाता है। Azure Monitor alerts सेट करें जब groundedness गिरे या safety thresholds breach हों।

सब कुछ Azure Monitor Application Insights में publish होता है। Agent quality, infrastructure health, cost, और app telemetry — सब एक ही जगह।

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Hosted agents के लिए छह नए regions

Hosted agents अब East US, North Central US, Sweden Central, Southeast Asia, Japan East, और अन्य में उपलब्ध हैं। यह data residency requirements के लिए और latency कम करने के लिए मायने रखता है जब आपका agent अपने data sources के करीब चलता है।

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

भले ही GA announcement के code samples Python-first हों, underlying infrastructure language-agnostic है — और azure-ai-projects का .NET SDK वही patterns follow करता है। Responses API, evaluation framework, private networking, MCP auth — यह सब .NET से उपलब्ध है।

अगर आप AI agents के “cool demo” से “मैं इसे actually काम पर ship कर सकता हूँ” बनने का इंतज़ार कर रहे थे, तो यह GA release वह signal है। Private networking, proper auth, continuous evaluation, और production monitoring वे टुकड़े थे जो missing थे।

निष्कर्ष

Foundry Agent Service अभी उपलब्ध है। SDK install करें, portal खोलें, और build करना शुरू करें। Quickstart guide आपको zero से एक running agent तक minutes में ले जाती है।

सभी code samples के साथ पूरे technical deep-dive के लिए, GA announcement देखें।

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 देखें।

Microsoft Agent Framework में Background Responses: Timeout की चिंता अब खत्म

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

अगर आपने o3 या GPT-5.2 जैसे reasoning models के साथ कुछ बनाया है, तो आप वो दर्द जानते हैं। आपका agent एक complex task पर सोचना शुरू करता है, client वहाँ इंतज़ार करता है, और “यह ठीक है” से “क्या यह crash हो गया?” के बीच कहीं आपका connection timeout हो जाता है। वो सारा काम? बेकार।

Microsoft Agent Framework ने background responses ship किए हैं — और सच में, यह उन features में से एक है जो पहले दिन से ही होना चाहिए था।

Blocking calls की समस्या

एक पारंपरिक request-response pattern में, आपका client तब तक block रहता है जब तक agent finish नहीं हो जाता। यह quick tasks के लिए ठीक काम करता है। लेकिन जब आप एक reasoning model से deep research, multi-step analysis, या 20-page report generate करने को कहते हैं? आप wall-clock time में मिनटों की बात कर रहे हैं। उस window के दौरान:

HTTP connections timeout हो सकते हैं
Network blips पूरे operation को बर्बाद कर देते हैं
आपका user spinner देखता है और सोचता है कि कुछ हो भी रहा है या नहीं

Background responses इसे उलट देते हैं।

Continuation tokens कैसे काम करते हैं

Block होने की बजाय, आप agent task kick off करते हैं और एक continuation token वापस पाते हैं। इसे एक repair shop के claim ticket की तरह समझें — आप counter पर खड़े नहीं रहते, आप तब वापस आते हैं जब वो तैयार हो जाए।

Flow सीधा है:

अपना request AllowBackgroundResponses = true के साथ भेजें
अगर agent background processing support करता है, तो आपको एक continuation token मिलता है
अपने schedule पर poll करें जब तक token null न आ जाए — इसका मतलब है result तैयार है

यहाँ .NET version है:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

अगर agent तुरंत complete हो जाता है (simple tasks, वे models जिन्हें background processing की ज़रूरत नहीं), तो कोई continuation token return नहीं होता। आपका code बस काम करता है — कोई special handling ज़रूरी नहीं।

Resume के साथ Streaming: असली जादू

Fire-and-forget scenarios के लिए polling ठीक है, लेकिन जब आप real-time progress चाहते हों? Background responses built-in resumption के साथ streaming भी support करते हैं।

हर streamed update अपना खुद का continuation token carry करता है। अगर mid-stream आपका connection drop हो जाए, तो आप ठीक वहीं से pick up करते हैं जहाँ छोड़ा था:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Agent server-side processing जारी रखता है चाहे आपके client के साथ कुछ भी हो रहा हो। यह built-in fault tolerance है बिना आपके retry logic या circuit breakers लिखे।

इसे वास्तव में कब use करें

हर agent call को background responses की ज़रूरत नहीं है। Quick completions के लिए, आप बिना किसी कारण complexity जोड़ रहे होंगे। लेकिन यहाँ वे shine करते हैं:

Complex reasoning tasks — multi-step analysis, deep research, कुछ भी जो reasoning model को वास्तव में सोचने पर मजबूर करे
Long content generation — detailed reports, multi-part documents, extensive analysis
Unreliable networks — mobile clients, edge deployments, flaky corporate VPNs
Async UX patterns — task submit करें, कुछ और करें, results के लिए वापस आएं

हम .NET developers जो enterprise apps बना रहे हैं, उनके लिए वो आखिरी scenario खास दिलचस्प है। एक Blazor app के बारे में सोचें जहाँ user एक complex report request करता है — आप agent task fire off करते हैं, उन्हें एक progress indicator दिखाते हैं, और उन्हें काम करते रहने देते हैं। कोई WebSocket gymnastics नहीं, कोई custom queue infrastructure नहीं, बस एक token और एक poll loop।

निष्कर्ष

Background responses Microsoft Agent Framework में अभी .NET और Python दोनों के ज़रिए उपलब्ध हैं। अगर आप ऐसे agents बना रहे हैं जो simple Q&A से ज़्यादा complex कुछ करते हैं, तो यह अपने toolkit में जोड़ने लायक है। Continuation token pattern चीज़ों को simple रखता है जबकि एक बहुत real production problem solve करता है।

Complete API reference और अधिक examples के लिए full documentation देखें।

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 करने को कहता है। “उम्मीद है कोई कुछ अजीब नहीं करेगा” वाले तरीके से कहीं बेहतर।

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 करें।

Posts | The .NET Blog

.NET 10 Ubuntu 26.04 LTS के साथ आया — क्या नया है

.NET 10 दो commands में install करें

Containers: -noble को -resolute में बदलें

Native AOT: 3ms startup, 1.4MB binary

.NET 8 या 9 चाहिए?

Agent Framework में CodeAct: अपने एजेंट की लेटेंसी को आधा कैसे करें

CodeAct क्या है?

सुरक्षा: Hyperlight माइक्रो-VM

न्यूनतम सेटअप

कब CodeAct उपयोग करें

अभी आज़माएं

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

MCP Bundle क्या है?

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

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

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

GPT-5.5 आ गया Azure Foundry में — .NET डेवलपर्स को क्या जानना चाहिए

GPT-5 की प्रगति

वास्तव में क्या बदला

मूल्य निर्धारण

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

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

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

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

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

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

TypeScript 7.0 Nightly ऑप्ट-इन

आपका एजेंट चीजें कहाँ याद रखता है? चैट हिस्ट्री स्टोरेज का व्यावहारिक गाइड

दो बुनियादी पैटर्न

Agent Framework कैसे अमूर्त करता है

प्रदाता त्वरित संदर्भ

कैसे चुनें

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 ऑटोमेशन

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

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

azd + GitHub Copilot: AI-सहायता से प्रोजेक्ट सेटअप और स्मार्ट एरर समाधान

azd init में Copilot के साथ सेटअप

असल में क्या होता है

Copilot से एरर ट्रबलशूटिंग

डिफ़ॉल्ट व्यवहार सेट करें

निष्कर्ष

Node.js के लिए C# में नेटिव ऐडऑन लिखना .NET Native AOT के साथ

बुनियादी विचार

प्रोजेक्ट सेटअप

एंट्री पॉइंट एक्सपोर्ट करना

TypeScript से कॉल करना

निष्कर्ष

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

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

निष्कर्ष

Azure पर आपके AI प्रयोग पैसे बर्बाद कर रहे हैं — इसे ठीक करने का तरीका यहाँ है

AI Workloads क्यों अलग हैं

Management बनाम Optimization — अंतर जानें

जो वास्तव में काम करता है

Containers: `-noble` को `-resolute` में बदलें