.NET | 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 के बारे में अधिक जानकारी है।

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 ब्लॉग पर मूल पोस्ट पढ़ें।

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