.NET 11 ने अंततः प्रोसेस API को ठीक किया

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

हर .NET डेवलपर जिसे कभी एक प्रोसेस शुरू करके उसका आउटपुट कैप्चर करना पड़ा है, उसने उसी खतरनाक बॉयलरप्लेट कोड का कोई न कोई वेरिएशन लिखा है: stdout से async रीड, stderr से async रीड, WaitForExitAsync, दोनों स्ट्रीम को ड्रेन करना न भूलें वरना डेडलॉक हो जाएगा। यह एक जानी-पहचानी समस्या है जो वर्षों से चली आ रही है।

.NET 11 अंततः इसे सही ढंग से ठीक करता है।

RunAndCaptureTextAsync

मुख्य जोड़: एक सिंगल स्टैटिक मेथड जो एक प्रोसेस शुरू करता है, stdout और stderr कैप्चर करता है, और डेडलॉक के बिना एग्जिट का इंतजार करता है।

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

एक कॉल। कोई मैनुअल स्ट्रीम ड्रेनिंग नहीं। कोई सावधानी से रखा गया WaitForExit नहीं। अगर आपको बस कुछ रन करना है और उसका आउटपुट चाहिए, तो यही वो API है।

आउटपुट कैप्चर किए बिना एग्जिट का इंतजार करने के लिए Process.RunAsync भी है।

KillOnParentExit

शुरू किए गए प्रोसेस की एक सामान्य समस्या: अगर पैरेंट क्रैश हो जाए या बंद हो जाए, तो चाइल्ड प्रोसेस अनाथ की तरह चलते रहते हैं। KillOnParentExit आपको प्रोसेस शुरू करते वक्त घोषित करने देता है कि पैरेंट प्रोसेस के बंद होने पर चाइल्ड प्रोसेस भी बंद हो जाए।

यह एक ऐसी सुविधा थी जो प्लेटफॉर्म-विशिष्ट तरीकों से मौजूद थी (Windows पर job objects, Linux पर prctl) लेकिन .NET से इस्तेमाल करने के लिए p/invoke या थर्ड-पार्टी लाइब्रेरी की जरूरत थी। अब यह ProcessStartInfo पर एक फर्स्ट-क्लास प्रॉपर्टी है।

SafeProcessHandle-आधारित API

नई लाइटवेट API सर्फेस पूर्ण Process क्लास के बजाय SafeProcessHandle के आसपास बनाई गई है। पूर्ण Process क्लास बहुत सारी स्थिति लेकर चलती है और इसे ट्रिम करना मुश्किल है — SafeProcessHandle पाथ उन एप्लीकेशन के लिए ज़्यादा ट्रिमर-फ्रेंडली है जिन्हें आउटपुट साइज़ कम करनी है (WASM, नेटिव AOT)।

हैंडल इनहेरिटेंस पर पूरा नियंत्रण

अपडेट में यह भी जोड़ा गया है कि एक चाइल्ड प्रोसेस कौन से हैंडल इनहेरिट करता है और स्टैंडर्ड हैंडल कैसे रीडायरेक्ट होते हैं, इस पर बारीक नियंत्रण। पहले आप stdin/stdout/stderr रीडायरेक्ट कर सकते थे, लेकिन OS स्तर पर ठीक-ठीक कौन से हैंडल इनहेरिट करने हैं यह नहीं बता सकते थे। नई APIs वो नियंत्रण देती हैं।

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

Process क्लास tooling, build सिस्टम, test रनर, और किसी भी एप्लीकेशन में उपयोग होती है जो अन्य executables को कॉल करती है। पुरानी API सर्फेस .NET Framework के ज़माने की थी। यह कोई ब्रेकिंग चेंज नहीं है — पुरानी API काम करती रहती है — लेकिन नए कोड को नई सर्फेस को प्राथमिकता देनी चाहिए।

ट्रिम्ड एप्लीकेशन या AOT कंपाइलेशन परिदृश्यों के लिए, SafeProcessHandle पाथ विशेष रूप से स्वागत योग्य है। पुरानी Process क्लास बहुत सारा reflection-heavy कोड लाती थी जो ट्रिमिंग को जटिल बनाता था।