<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Modernization | The .NET Blog</title><link>https://thedotnetblog.com/hi/tags/modernization/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>hi</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Fri, 17 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/hi/tags/modernization/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker Sandbox, Copilot Agents को आपकी मशीन को जोखिम में डाले बिना Code Refactor करने देता है</title><link>https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/copilot-docker-sandbox-agentic-refactoring/</link><pubDate>Fri, 17 Apr 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/copilot-docker-sandbox-agentic-refactoring/</guid><description>Docker Sandbox, GitHub Copilot agents को refactoring के लिए एक सुरक्षित microVM देता है — कोई permission prompt नहीं, host को कोई खतरा नहीं। यहाँ जानें यह बड़े पैमाने पर .NET modernization के लिए सब कुछ कैसे बदलता है।</description><content:encoded>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, &lt;a href="https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/copilot-docker-sandbox-agentic-refactoring/"&gt;यहाँ क्लिक करें&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;अगर आपने Copilot के agent mode का उपयोग छोटे edits से परे किसी काम के लिए किया है, तो आप वह तकलीफ जानते हैं। हर file write, हर terminal command — एक और permission prompt। अब कल्पना करें कि यह 50 projects में चलाना हो। मज़ेदार नहीं।&lt;/p&gt;
&lt;p&gt;Azure team ने &lt;a href="https://devblogs.microsoft.com/all-things-azure/best-of-both-worlds-for-agentic-refactoring-github-copilot-microvms-via-docker-sandbox/"&gt;GitHub Copilot agents के लिए Docker Sandbox&lt;/a&gt; के बारे में एक post publish किया है, और सच में, यह सबसे practical agentic tooling improvements में से एक है जो मैंने देखी है। यह microVMs का उपयोग करता है ताकि Copilot को एक पूरी तरह से isolated environment मिल सके जहाँ यह खुलकर काम कर सके — packages install करना, builds चलाना, tests execute करना — आपके host system को छुए बिना।&lt;/p&gt;
&lt;h2 id="docker-sandbox-वसतव-म-कय-दत-ह"&gt;Docker Sandbox वास्तव में क्या देता है&lt;/h2&gt;
&lt;p&gt;Core idea सरल है: एक पूर्ण Linux environment के साथ एक lightweight microVM spin up करें, अपना workspace उसमें sync करें, और Copilot agent को उसके अंदर freely काम करने दें। जब यह हो जाए, changes sync back हो जाती हैं।&lt;/p&gt;
&lt;p&gt;यहाँ वह है जो इसे सिर्फ &amp;ldquo;container में चीज़ें चलाने&amp;rdquo; से अधिक बनाता है:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Bidirectional workspace sync&lt;/strong&gt; जो absolute paths को preserve करता है। आपकी project structure sandbox के अंदर बिल्कुल एक जैसी दिखती है। Path-related build failures नहीं।&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Private Docker daemon&lt;/strong&gt; जो microVM के अंदर चलता है। Agent containers build और run कर सकता है बिना कभी आपके host के Docker socket को mount किए। Security के लिए यह बहुत बड़ी बात है।&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;HTTP/HTTPS filtering proxies&lt;/strong&gt; जो control करते हैं कि agent network पर क्या reach कर सकता है। आप तय करते हैं कि कौन-से registries और endpoints allowed हैं। Sandbox के अंदर एक rogue &lt;code&gt;npm install&lt;/code&gt; से supply chain attacks? Blocked।&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;YOLO mode&lt;/strong&gt; — हाँ, यही वे इसे कहते हैं। Agent बिना permission prompts के चलता है क्योंकि यह literally आपके host को नुकसान नहीं पहुँचा सकता। हर destructive action contained है।&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="net-developers-क-कय-परवह-करन-चहए"&gt;.NET Developers को क्यों परवाह करनी चाहिए&lt;/h2&gt;
&lt;p&gt;उस modernization work के बारे में सोचें जिसका सामना इतनी सारी teams कर रही हैं। आपके पास 30 projects का एक .NET Framework solution है, और आपको इसे .NET 9 पर move करना है। वह सैकड़ों file changes हैं — project files, namespace updates, API replacements, NuGet migrations।&lt;/p&gt;
&lt;p&gt;Docker Sandbox के साथ, आप एक Copilot agent को किसी project पर point कर सकते हैं, उसे microVM के अंदर freely refactor करने दे सकते हैं, validate करने के लिए &lt;code&gt;dotnet build&lt;/code&gt; और &lt;code&gt;dotnet test&lt;/code&gt; चला सकते हैं, और केवल वे changes accept कर सकते हैं जो वास्तव में काम करती हैं। इस जोखिम के बिना कि experimenting करते समय यह आपके local dev environment को accidentally बर्बाद कर दे।&lt;/p&gt;
&lt;p&gt;Post में &lt;strong&gt;parallel agents की एक fleet&lt;/strong&gt; चलाने का भी वर्णन है — प्रत्येक अपने sandbox में — जो एक साथ अलग-अलग projects से निपटती हैं। बड़े .NET solutions या microservice architectures के लिए, यह बहुत बड़ा समय बचाने वाला है। एक agent per service, सभी isolated होकर चल रहे हैं, सभी independently validate हो रहे हैं।&lt;/p&gt;
&lt;h2 id="security-पकष-मयन-रखत-ह"&gt;Security पक्ष मायने रखता है&lt;/h2&gt;
&lt;p&gt;यहाँ वह बात है जो ज़्यादातर लोग छोड़ देते हैं: जब आप एक AI agent को arbitrary commands execute करने देते हैं, तो आप उस पर अपनी पूरी machine का भरोसा कर रहे हैं। Docker Sandbox उस model को पलट देता है। Agent को एक throwaway environment के अंदर पूरी autonomy मिलती है। Network proxy सुनिश्चित करता है कि यह केवल approved sources से pull कर सकता है। आपका host filesystem, Docker daemon, और credentials अछूते रहते हैं।&lt;/p&gt;
&lt;p&gt;Compliance requirements वाली teams के लिए — और ज़्यादातर enterprise .NET shops की यही स्थिति है — यह &amp;ldquo;हम agentic AI उपयोग नहीं कर सकते&amp;rdquo; और &amp;ldquo;हम इसे safely adopt कर सकते हैं&amp;rdquo; के बीच का अंतर है।&lt;/p&gt;
&lt;h2 id="नषकरष"&gt;निष्कर्ष&lt;/h2&gt;
&lt;p&gt;Docker Sandbox agentic coding के मूलभूत tension को हल करता है: agents को उपयोगी होने के लिए स्वतंत्रता चाहिए, लेकिन आपकी host machine पर स्वतंत्रता खतरनाक है। MicroVMs आपको दोनों देते हैं। अगर आप कोई बड़े पैमाने का .NET refactoring या modernization plan कर रहे हैं, तो इसे अभी set up करना उचित है। Copilot की code intelligence को एक safe execution environment के साथ मिलाना ठीक वही है जिसका production teams इंतज़ार कर रही थीं।&lt;/p&gt;</content:encoded></item><item><title>GitHub Copilot का Modernization Assessment सबसे अच्छा Migration Tool है जिसे आप अभी तक Use नहीं कर रहे</title><link>https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/dotnet-modernization-assessment-github-copilot/</link><pubDate>Fri, 10 Apr 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/dotnet-modernization-assessment-github-copilot/</guid><description>GitHub Copilot का modernization extension केवल code changes suggest नहीं करता — यह actionable issues, Azure target comparisons, और collaborative workflow के साथ एक पूरी migration assessment तैयार करता है। यहाँ जानें क्यों assessment document ही सब कुछ की कुंजी है।</description><content:encoded>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, &lt;a href="https://thedotnetblog.com/hi/posts/emiliano-montesdeoca/dotnet-modernization-assessment-github-copilot/"&gt;यहाँ क्लिक करें&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;एक legacy .NET Framework app को modern .NET पर migrate करना उन कामों में से एक है जो सब जानते हैं करना चाहिए, लेकिन कोई शुरू नहीं करना चाहता। यह कभी सिर्फ &amp;ldquo;target framework बदलो&amp;rdquo; नहीं होता। APIs गायब हो गई हैं, packages अब exist नहीं करते, hosting models बिल्कुल अलग तरह से काम करते हैं, और हज़ारों छोटे decisions हैं — क्या containerize करना है, क्या rewrite करना है, और क्या छोड़ना है।&lt;/p&gt;
&lt;p&gt;Jeffrey Fritz ने &lt;a href="https://devblogs.microsoft.com/dotnet/your-migrations-source-of-truth-the-modernization-assessment/"&gt;GitHub Copilot के modernization assessment का विस्तृत विश्लेषण&lt;/a&gt; publish किया है, और सच में? .NET के लिए यह सबसे अच्छा migration tooling है जो मैंने देखा है। Code generation की वजह से नहीं — वह तो अब baseline है। बल्कि उस assessment document की वजह से जो यह तैयार करता है।&lt;/p&gt;
&lt;h2 id="यह-सरफ-code-suggestion-engine-नह-ह"&gt;यह सिर्फ Code Suggestion Engine नहीं है&lt;/h2&gt;
&lt;p&gt;VS Code extension एक &lt;strong&gt;Assess → Plan → Execute&lt;/strong&gt; model follow करता है। Assessment phase आपके पूरे codebase का विश्लेषण करती है और एक structured document तैयार करती है जो सब कुछ capture करती है: क्या बदलने की ज़रूरत है, कौन-से Azure resources provision करने हैं, कौन-सा deployment model उपयोग करना है। Infrastructure-as-code, containerization, deployment manifests — सब कुछ assessment के findings से निकलता है।&lt;/p&gt;
&lt;p&gt;Assessment आपके project में &lt;code&gt;.github/modernize/assessment/&lt;/code&gt; के अंतर्गत store होती है। हर run एक independent report तैयार करता है, इसलिए आप एक history बनाते हैं और track कर सकते हैं कि जैसे-जैसे आप issues fix करते हैं आपकी migration posture कैसे evolve होती है।&lt;/p&gt;
&lt;h2 id="शर-करन-क-द-तरक"&gt;शुरू करने के दो तरीके&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Recommended Assessment&lt;/strong&gt; — fast path। Curated domains (Java/.NET Upgrade, Cloud Readiness, Security) में से चुनें और configuration को छुए बिना meaningful results प्राप्त करें। यह देखने के लिए excellent है कि आपकी app कहाँ खड़ी है।&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Custom Assessment&lt;/strong&gt; — targeted path। ठीक वही configure करें जो analyze करना है: target compute (App Service, AKS, Container Apps), target OS, containerization analysis। Migration approaches की side-by-side तुलना के लिए multiple Azure targets चुनें।&lt;/p&gt;
&lt;p&gt;वह comparison view सच में उपयोगी है। App Service के लिए 3 mandatory issues वाली एक app के लिए AKS पर 7 हो सकती हैं। दोनों देखने से migration path commit करने से पहले hosting decision drive करने में मदद मिलती है।&lt;/p&gt;
&lt;h2 id="issue-breakdown-actionable-ह"&gt;Issue Breakdown Actionable है&lt;/h2&gt;
&lt;p&gt;हर issue एक criticality level के साथ आती है:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Mandatory&lt;/strong&gt; — ठीक करना ज़रूरी है या migration fail होगी&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Potential&lt;/strong&gt; — migration को affect कर सकती है, human judgment ज़रूरी है&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Optional&lt;/strong&gt; — recommended improvements, migration block नहीं करेंगी&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;और हर issue affected files और line numbers से link करती है, बताती है कि क्या गलत है और आपके target platform के लिए यह क्यों मायने रखता है, concrete remediation steps देती है (सिर्फ &amp;ldquo;यह ठीक करो&amp;rdquo; नहीं), और official documentation के links include करती है।&lt;/p&gt;
&lt;p&gt;आप individual issues developers को सौंप सकते हैं और उनके पास act करने के लिए सब कुछ है। यही फ़र्क है एक ऐसे tool में जो आपको &amp;ldquo;एक problem है&amp;rdquo; बताता है और एक जो आपको बताता है कि इसे कैसे solve करना है।&lt;/p&gt;
&lt;h2 id="covered-upgrade-paths"&gt;Covered Upgrade Paths&lt;/h2&gt;
&lt;p&gt;.NET के लिए specifically:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;.NET Framework → .NET 10&lt;/li&gt;
&lt;li&gt;ASP.NET → ASP.NET Core&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;हर upgrade path में detection rules हैं जो जानती हैं कि कौन-से APIs हटाए गए, कौन-से patterns का कोई direct equivalent नहीं है, और किन security issues पर ध्यान देना है।&lt;/p&gt;
&lt;p&gt;Multiple apps manage करने वाली teams के लिए, एक CLI भी है जो multi-repo batch assessments support करती है — सभी repos clone करें, सभी assess करें, per-app reports और एक aggregated portfolio view प्राप्त करें।&lt;/p&gt;
&lt;h2 id="मर-रय"&gt;मेरी राय&lt;/h2&gt;
&lt;p&gt;अगर आप legacy .NET Framework apps पर बैठे हैं (और सच में, ज़्यादातर enterprise teams ऐसी ही हैं), तो यही &lt;em&gt;वह&lt;/em&gt; tool है जिससे शुरू करना चाहिए। Assessment document अकेले समय के लायक है — यह एक अस्पष्ट &amp;ldquo;हमें modernize करना चाहिए&amp;rdquo; को स्पष्ट, prioritized work items की एक concrete list में बदलता है जिनके आगे बढ़ने के clear paths हैं।&lt;/p&gt;
&lt;p&gt;Collaborative workflow भी smart है: assessments export करें, अपनी team के साथ share करें, बिना re-run किए import करें। Architecture reviews जहाँ decision-makers वे नहीं हैं जो tools चला रहे हैं? Covered।&lt;/p&gt;
&lt;h2 id="नषकरष"&gt;निष्कर्ष&lt;/h2&gt;
&lt;p&gt;GitHub Copilot का modernization assessment .NET migration को एक डरावने, undefined project से एक structured, trackable process में बदलता है। अपना current status देखने के लिए recommended assessment से शुरू करें, फिर Azure targets की तुलना करने और अपना migration plan बनाने के लिए custom assessments उपयोग करें।&lt;/p&gt;
&lt;p&gt;&lt;a href="https://devblogs.microsoft.com/dotnet/your-migrations-source-of-truth-the-modernization-assessment/"&gt;पूरा walkthrough&lt;/a&gt; पढ़ें और अपने codebase पर इसे आज़माने के लिए &lt;a href="https://aka.ms/ghcp-appmod/vscode-ext"&gt;VS Code extension&lt;/a&gt; लें।&lt;/p&gt;</content:encoded></item></channel></rss>