`dotnet run app.cs` से C# फ़ाइलों को सीधे चलाने का तरीका

 (devblogs.microsoft.com)
4 पॉइंट द्वारा GN⁺ 2025-05-30 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • .NET 10 Preview 4 से अब एक single C# फ़ाइल को dotnet run app.cs से सीधे चलाया जा सकता है, यानी project file के बिना भी C# code execute करना संभव हो गया है
  • file-based apps की वजह से Python या JavaScript की तरह आसान script execution, testing और idea experimentation अब और भी सरल हो गया है
  • NuGet package references, SDK selection, build property settings जैसी चीज़ें भी फ़ाइल के अंदर directives से manage की जा सकती हैं, जिससे development flexibility बढ़ती है
  • shebang support के साथ Unix जैसे systems में CLI utilities और automation scripts के लिए भी इसका उपयोग किया जा सकता है
  • ज़रूरत पड़ने पर इसे आसानी से project-based app में बदला जा सकता है, इसलिए learning और prototyping से लेकर full-scale app development तक इसका natural flow बनता है

dotnet run app.cs क्या है

  • पहले dotnet CLI से C# code चलाने के लिए project (.csproj) structure ज़रूरी होता था
  • अब सिर्फ एक .cs फ़ाइल से सीधे execution संभव है, जिससे entry barrier काफ़ी कम हो गया है
  • यह scripting languages, automation, experimentation और learning जैसे कई उपयोगों के लिए उपयुक्त है
  • CLI integration की वजह से अतिरिक्त tools install किए बिना, सिर्फ dotnet होने पर इसे तुरंत इस्तेमाल किया जा सकता है
  • अगर code बड़ा हो जाए, तो उसी language और tools के साथ इसे project-based app में expand किया जा सकता है

file-level directives support

  • file-based apps में भी project की मुख्य settings को सीधे .cs फ़ाइल के अंदर directives के रूप में declare किया जा सकता है

  • NuGet package reference

    • #:package directive से NuGet package को सीधे reference किया जा सकता है
      • उदाहरण: 
        #:package Humanizer@2.14.1  

using Humanizer;  

var dotNet9Released = DateTimeOffset.Parse("2024-12-03");  
var since = DateTimeOffset.Now - dotNet9Released;  

Console.WriteLine($"It has been {since.Humanize()} since .NET 9 was released.");

  • SDK selection

    • #:sdk directive से SDK type specify किया जा सकता है
      • उदाहरण: 
        #:sdk Microsoft.NET.Sdk.Web
      • इससे ASP.NET Core features जैसे minimal API, MVC आदि भी enable किए जा सकते हैं

  • MSBuild property settings

    • #:property से build properties को सीधे set किया जा सकता है
      • उदाहरण: 
        #:property LangVersion preview

  • shell scripts के लिए shebang support

    • फ़ाइल के सबसे ऊपर #!/usr/bin/dotnet run जोड़कर इसे Unix systems में executable file की तरह सीधे इस्तेमाल किया जा सकता है
      • उदाहरण: 
        #!/usr/bin/dotnet run  
Console.WriteLine("Hello from a C# script!");
      • execute permission देने के बाद सीधे चलाएँ: 
        chmod +x app.cs  
./app.cs

project-based app में conversion

  • जब app बड़ा हो जाए या ज़्यादा features चाहिए हों, तब dotnet project convert app.cs command से इसे आसानी से project में convert किया जा सकता है
  • directives अपने-आप .csproj फ़ाइल की properties, references आदि में बदल जाते हैं

  • conversion example

    • इस तरह की फ़ाइल: 
      #:sdk Microsoft.NET.Sdk.Web  
#:package Microsoft.AspNetCore.OpenApi@10.*-*  

var builder = WebApplication.CreateBuilder();  
builder.Services.AddOpenApi();  
var app = builder.Build();  
app.MapGet("/", () => "Hello, world!");  
app.Run();
    • conversion result:
    <Project Sdk="Microsoft.NET.Sdk.Web">  
  <PropertyGroup>  
    <TargetFramework>net10.0</TargetFramework>  
    <ImplicitUsings>enable</ImplicitUsings>  
    <Nullable>enable</Nullable>  
  </PropertyGroup>  
  <ItemGroup>  
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="10.*-*" />  
  </ItemGroup>  
</Project>

मौजूदा C# scripting तरीकों से अंतर

  • अब तक community tools जैसे CS-Script, dotnet-script, Cake आदि से C# scripts चलाए जा सकते थे, लेकिन इनके लिए अलग tools install और configure करने पड़ते थे
  • अब बिना किसी अलग installation या mode के, वही C# compiler और language इस्तेमाल करते हुए तुरंत code चलाया जा सकता है

शुरू कैसे करें

  • .NET 10 Preview 4 install करें
  • अगर आप Visual Studio Code इस्तेमाल करते हैं, तो C# Dev Kit और C# extension का latest pre-release version (2.79.8 या उससे ऊपर) install करना होगा
  • .cs फ़ाइल बनाएँ और सीधे code लिखें
  • terminal में dotnet run hello.cs चलाएँ
  • ज़रूरत हो तो dotnet project convert hello.cs से project में convert करें

और जानें

आगे की योजना

  • VS Code में file-based apps support और directives के लिए IntelliSense सुधार, performance improvement और debugging support को और बेहतर बनाया जाएगा
  • multi-file support और execution speed improvement जैसी अतिरिक्त features पर भी काम चल रहा है
  • dotnet run app.cs C# को और आसान बनाता है, साथ ही .NET की पूरी ताकत भी देता है
  • prototyping, education और production development के बीच तेज़ transition के लिए यह मज़बूत आधार देता है

संबंधित पढ़ाई

4 टिप्पणियां

 
rkttu 2025-08-18

File-based App पर आधारित auto-completion experience देने वाला DX, C# extension के नवीनतम संस्करण में उपलब्ध है, लेकिन मूल रूप से Microsoft इस extension को VS Code Marketplace के अलावा किसी और जगह पर प्रकाशित नहीं कर रहा था.

इस असुविधा को दूर करने के लिए, C# Dev Kit नहीं बल्कि C# Extension वाले हिस्से (MIT license वाला हिस्सा) को अलग से autobuild/auto-publish करने के लिए बनाया गया, उसे OpenVSX पर रजिस्टर किया गया, और इसी के आधार पर Kiro-आधारित एक सरल demo video साझा की जा रही है.

https://www.youtube.com/watch?v=pIi7CWOPQSA
 
ndrgrd 2025-05-31

जब मैंने पहले C# Interactive फीचर इस्तेमाल किया था, तब लोकल में इंस्टॉल न किए गए पैकेज इस्तेमाल नहीं किए जा सकते थे, लेकिन अब लगता है कि इसमें सुधार हो गया है।
 
GN⁺ 2025-05-30
Hacker News राय
  • यह फ़ीचर .NET डेवलपर प्रोडक्टिविटी पर बड़ा असर डाल सकता है, इसलिए थोड़ा अफ़सोस भी होता है कि यह अब जाकर क्यों आया। और .NET प्रोजेक्ट्स में एक फ़ीचर की सच में इच्छा है: हर प्रोजेक्ट के लिए आसानी से custom commands define करने की सुविधा। उदाहरण के लिए, अगर npm run <command> जैसा कोई तरीका हो तो अच्छा होगा
    • मैं https://github.com/dotnet-script/dotnet-script इस्तेमाल कर रहा हूँ और बिना किसी खास समस्या के ठीक चल रहा है, फिर भी अगर कुछ झंझट वाले स्टेप्स छोड़े जा सकें तो और अच्छा लगेगा
    • क्या आपका मतलब https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run जैसी किसी चीज़ से है?
    • अगर ऐसा फ़ीचर हो तो सच में बहुत अच्छा होगा। मैं अभी इसे make फ़ाइल से लागू करके इस्तेमाल कर रहा हूँ https://www.gnu.org/software/make/
    • सच कहूँ तो make या task जैसे अलग task runner का इस्तेमाल करना शायद बेहतर भी हो सकता है
    • पहले जब मुझे ऐसी सुविधा चाहिए होती थी, तब मैंने LINQPad भी इस्तेमाल किया था
  • यह दिलचस्प है कि इसे shebang के साथ सक्रिय रूप से इस्तेमाल करने के लिए प्रचारित किया जा रहा है। यह तरीका काफ़ी आकर्षक लगता है। Go भी modules आने से पहले इस तरह scripting के लिए उपयोगी था, और याद पड़ता है कि Ubuntu में भी इसे ऐसे ही इस्तेमाल किया गया था। लेकिन Go के लेखकों का Go को इस तरह scripting language की तरह इस्तेमाल करने पर नकारात्मक रुख था
    • Go के लेखकों ने विरोध नहीं किया था, बल्कि वे चाहते थे कि Go को प्राथमिक रूप से programming language की तरह इस्तेमाल किया जाए। gorun (https://github.com/erning/gorun) जैसे tools से Go को पहले से ही आसानी से script की तरह चलाया जा सकता था। हाल में यह भी support हुआ है कि टैग सीधे लेकर एक ही बार में चलाया जा सके, जैसे go run github.com/kardianos/json/cmd/jsondiff@v1.0.1। यह काफ़ी शानदार फ़ीचर है
    • सोच रहा हूँ कि ‘shebang’ शब्द कहाँ से और कब से इस्तेमाल होने लगा। यूनिवर्सिटी के समय और 90~2000 के शुरुआती दौर में दक्षिणी इलाक़ों में इसे आम तौर पर hashbang कहा जाता था। shebang शब्द मैंने पहली बार C# के लोकप्रिय होने के बाद सुना, जबकि असल में यह उससे पहले का शब्द है। बस मेरे आसपास यह सुनने को नहीं मिला था
    • पहले जब मैं एक .NET कंपनी में काम करता था, तो कोई अचानक bash में automation scripts लिख देता था। ऐसे scripts को लंबे समय तक maintain करने की expertise नहीं थी, और पहली बार लिखते समय भी उनकी quality अच्छी नहीं थी। तब समझ नहीं आता था कि tool को सीधे C# में ही क्यों नहीं बनाया गया। इस फ़ीचर की वजह से C# वाला तरीका अब कहीं ज़्यादा व्यावहारिक विकल्प लग सकता है
    • Rust के cargo से भी ऐसा किया जा सकता है, लेकिन अभी यह आधिकारिक support नहीं है https://rust-lang.github.io/rfcs/3424-cargo-script.html
  • फ़ीचर अपने आप में शानदार है, लेकिन compiled होने पर भी startup overhead लगभग 0.5 सेकंड का है। इसलिए कई applications के लिए यह उपयुक्त नहीं हो सकता। फिर भी bash-आधारित shell scripting की सीमाएँ हैं, perl का दौर निकल चुका है, और Ruby अभी भी ऐसे कामों में बेहतरीन है इसलिए मैं उसे इस्तेमाल करता रहा हूँ। हाल में कुछ scripts को Swift में शिफ्ट किया है, जो मूल रूप से interpreter-style है इसलिए काफ़ी तेज़ लगता है, और compiled executables तो तुरंत चल पड़ते हैं, जो बहुत प्रभावशाली है। मैंने Swift CLI apps के लिए caching compiler भी खुद बनाया था (https://github.com/jrz/tools)। वैसे dotnet run पहले से compile results cache कर देता है, इसलिए अलग caching layer की ज़रूरत नहीं होती (disable करने के लिए --no-build, binary path देखने के लिए --artifacts-path)
    • 0.5 सेकंड वाला आँकड़ा कहाँ से आया, यह जानना चाहूँगा। मैंने hello world से test किया तो 63ms आया। neuecc की CLI library benchmark (https://neuecc.medium.com/consoleappframework-v5-zero-overhead-native-aot-compatible-cli-framework-for-c-8f496df8d9d1) देखें तो कुछ भी 0.5 सेकंड तक नहीं पहुँचता। और जहाँ Swift को मूल रूप से interpreter-style बताया गया, वहीं .NET JIT tiered JIT है, इसलिए code तुरंत नहीं बनता बल्कि कई चरणों में आगे बढ़ता है
    • सुना है कि dotnet में version 10 या 11 में पूरा interpreted mode आने वाला है। सोच रहा हूँ कि क्या यह mode ऐसे use case पर लागू होगा https://github.com/dotnet/runtime/issues/112748
    • अगर compiled होने के बाद भी startup में थोड़ा lag है, तो फिर यह सोचने वाली बात है कि Python इस क्षेत्र में इतना लोकप्रिय क्यों हुआ
    • यह फ़ीचर अभी शुरुआती preview चरण में है। कई presentations में बताया गया है कि startup speed की समस्या की जानकारी है और उस पर सुधार चल रहा है
    • अगर fast startup चाहिए तो https://learn.microsoft.com/en-us/dotnet/core/deploying/ के अनुसार इसे आसानी से native code में बदला जा सकता है
  • CSX/VBX projects का ज़िक्र कम है, यह थोड़ा खलता है https://ttu.github.io/dotnet-script/। यह भी दिलचस्प है कि फैसला ऐसे तरीके से हुआ जो C# runtime में F# scripts की dependency handling के साथ compatible नहीं लगता https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/
    • CSX/VBX जैसी कोशिशों के शामिल न होने की बात पर, यह बताया गया कि आधिकारिक रूप से कई तरीकों और tools का ज़िक्र किया गया है https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#existing-ways-to-run-c#-without-projects
    • F# के साथ incompatibility से क्या मतलब है, यह पूछा गया। अगर बात syntax differences की है, तो syntax जानबूझकर अलग रखा गया था, क्योंकि C# script dialect का नया रूप नहीं बनाना था, इसलिए file import जैसी सुविधाएँ जानबूझकर रोकी गईं। यह C# की प्रकृति से जुड़ा है
  • Kotlin में भी इसी तरह की सुविधा है, https://github.com/Kotlin/kotlin-script-examples/blob/master/jvm/main-kts/MainKts.md (यहाँ फ़ाइल extension ज़रूर *.main.kts होना चाहिए तभी यह काम करता है)। यह तरीका छोटे scripts या prototyping के लिए बहुत अच्छा है, और JVM capabilities का उपयोग करने में भी व्यावहारिक है। फिर भी छोटे scripts के लिए Ruby अब भी सबसे सहज है, खासकर external programs चलाते समय backtick syntax बहुत सुविधाजनक है
    • Kotlin scripting पूरी तरह गायब तो शायद नहीं होगी, लेकिन उसका भविष्य बहुत उज्ज्वल नहीं दिखता https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-scripting-2024/
    • मेरे हिसाब से Java में भी इसी तरह की scripting style आ चुकी है
  • shebang का इस्तेमाल करके C# scripts को bash scripts की तरह चलाया जा सकता है https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#using-shebang-lines-for-shell-scripts
    • .net10 preview 4 sdk image में फ़ाइल को सीधे चलाने के लिए shebang test किया था, लेकिन शुरुआत में यह सही नहीं चला। dotnet run <file> से काम हो गया, और update के बाद सीधे भी ठीक चलने लगा। समस्या की वजह यह थी कि फ़ाइल में LF के बजाय CRLF line endings थीं
    • अब type safety वाली scripts लिखी जा सकेंगी, यह बात बहुत अच्छी लगी। वैसे macOS पर shebang में #!/usr/local/share/dotnet/dotnet run या #!/usr/bin/env -S dotnet run लिखना पड़ता है
  • यह PowerShell का विकल्प बन सकता है। PowerShell का इस्तेमाल कभी-कभी लगभग ChatGPT-विशेष भाषा जैसा हो गया है। ज़्यादातर कंपनियों में PowerShell scripts infra की core भूमिका निभाती हैं, लेकिन अक्सर वे practically ‘read-only’ स्थिति में फँस जाती हैं
    • सिर्फ PowerShell ही नहीं, इससे कहीं बड़े दायरे को replace करने की क्षमता लगती है। अगर टीम .NET टीम है, तो Python या shell scripts छूने की ज़रूरत ही न पड़े—ऊपर shebang जोड़कर C# snippets चिपका दो और लगभग सारा scripting काम हो सकता है। Test service भी express.js में लिखने की जगह ASP.NET minimal API से झटपट बनाई जा सकती है
    • शायद Windows system administrators ही सबसे बड़े पैमाने पर ChatGPT-generated scripts इस्तेमाल करने वाला समूह होंगे। अगर मैं पहले जैसा admin होता, तो Microsoft documentation की गुणवत्ता देखते हुए मैं भी इसे ज़रूर इस्तेमाल करता
    • PowerShell से C# code को call करना भी संभव है https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/add-type?view=powershell-7.5
    • PowerShell में पूरी infrastructure को script के रूप में डाल देना वास्तव में आसान नहीं है, और ऐसा करने पर बस भारी अव्यवस्था पैदा होती है। सच में, कुछ functions से आगे जाते ही C# कहीं ज़्यादा efficient है और इसका entry barrier भी बहुत कम है। PowerShell छोटे ad-hoc scripts के लिए बेहतरीन है, और पुराने VBScript जैसी ‘Windows की default scripting language’ वाली जगह ले चुका है
    • क्योंकि PowerShell .NET code सीधे चला सकता है, इसलिए एक तरह से PowerShell का अनुभव और भी फैल जाता है
  • यह लगभग NetPad features की जगह लेता हुआ लगता है, और अगर debugging भी जुड़ गई तो LINQPad भी मुख्यधारा से पीछे छूट सकता है। मैंने भी पहले LINQPad से बहुत फ़ायदा लिया है, लेकिन आज के समय में उसका text editor experience अभी भी बहुत असुविधाजनक लगता है। गंभीर code writing या editing के लिए उसकी सीमाएँ साफ़ हैं
    • मेरे लिए LINQPad का मुख्य उपयोग DB interaction या .dump() से values explore करना है। यह नया dotnet run शायद उसे replace करने के बजाय complement करने वाला tool बन सकता है। पहले एक ऐसी जगह पर, जहाँ PowerShell से बेहद नफ़रत थी, LINQPad से लगभग सारा scripting काम होता था, और वहाँ यह काफ़ी उपयोगी था
    • LINQPad .NET ecosystem में वाकई unique product है, लेकिन उसका text editor कई बार लगभग सबसे खराब अनुभवों में से एक लगता है। काश उसे neovim या monaco जैसे editor से बदल दिया जाए। Table visualization और snappiness जैसी चीज़ें अच्छी हैं, लेकिन आजकल Jupyter Notebook जैसे ‘notebook’ tools की तुलना में इसका उपयोग-क्षेत्र सीमित है। शायद इसलिए भी कि इसे एक solo developer बना रहा है। फिर भी रोज़मर्रा के काम में SQL data संभालने के लिए LINQPad अब भी शानदार है
    • नहीं लगता कि LINQPad तुरंत replace हो जाएगा। उसकी आधी ताकत UI में है। VSCode या Visual Studio में dotnet run का अनुभव LINQPad से कितना मिलता-जुलता होगा, यह जानने की जिज्ञासा है। LINQPad की ताकत result visualization है। अगर dotnet run सिर्फ text output दे या बहुत plugins चाहिए हों, तो LINQPad की demand बनी रहेगी। हाँ, अगर सिर्फ syntax जाँचना हो तो dotnet run बेहतर विकल्प हो सकता है। मैं भी कभी-कभी उलझाने वाले syntax को LINQPad में आज़माता हूँ
    • जब तक GUI features और extension points सब लागू न हों, LINQPad को सीधे replace करना मुश्किल होगा
  • इस फ़ीचर का सच में इंतज़ार है। लगता है कि यह CI/CD pipeline में इस्तेमाल होने वाली मेरी कुछ PowerShell scripts को replace कर सकता है। मुझे PowerShell और Bash दोनों पसंद हैं, लेकिन कुछ काम ऐसे होते हैं जिन्हें दिमाग़ में C-style syntax वाली भाषा में हल करना कहीं ज़्यादा efficient होता है। यह फ़ीचर शायद वही खाली जगह भर सके
  • असली proposal (https://github.com/dotnet/sdk/blob/main/documentation/general/dotnet-run-file.md) में और भी काफ़ी जानकारी है, खासकर multiple files handling और implementation details (जैसे implicit project files) के बारे में विस्तार से बताया गया है
 
rkttu 2025-05-30

मैंने इस फीचर से जुड़े 2 वास्तविक उदाहरण भी बनाए हैं, इसलिए उन्हें जवाब में साझा कर रहा हूँ। ये MCP server और Avalonia का उपयोग करके बनाए गए Windows, macOS GUI app के sample code हैं। 😊

https://forum.dotnetdev.kr/t/…