Dotnet | The .NET Blog

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

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 सांस लेने दें।

.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 ऐसी चीज़ नहीं हैं जिन्हें आप टालें।

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

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

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 से शुरू करें।

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 हो गया है।

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

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

Dotnet | The .NET Blog

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

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

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

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

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

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

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

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

निष्कर्ष

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

एक property सबको control करे

स्वतंत्र clustering groups

Cluster taps handle करना

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

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

शुरुआत करें

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

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

Updated Versions

क्या करें

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

Azure MCP Server क्या है?

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

Security hardening

Getting started

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

Aspire as agent infrastructure

Bowling bumper analogy

शुरुआत करना

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

Fix: --isolated

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

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

इसे कब use करें

निष्कर्ष

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

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

Authentication के विकल्प

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

मेरा नज़रिया

निष्कर्ष

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

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

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

Issue Breakdown Actionable है

Covered Upgrade Paths

मेरी राय

निष्कर्ष

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

MCP Apps क्या हैं?

Fluent API तीन steps में

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

शुरुआत करें

निष्कर्ष

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

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

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

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

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

Single value या collection

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

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

बड़ी तस्वीर

आज ही आज़माएँ

निष्कर्ष

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

Fix: `--isolated`