Cara menjalankan file C# secara langsung dengan `dotnet run app.cs`

• Mulai .NET 10 Preview 4, kini tersedia fitur untuk langsung menjalankan satu file C# dengan dotnet run app.cs, sehingga kode C# bisa dijalankan tanpa file proyek
• Berkat file-based apps, menjalankan skrip sederhana, pengujian, dan eksperimen ide menjadi jauh lebih mudah, seperti di Python atau JavaScript
• Referensi paket NuGet, penentuan SDK, pengaturan properti build juga bisa dikelola melalui directive di dalam file, sehingga fleksibilitas pengembangan meningkat
• Dukungan shebang memungkinkan pemakaian untuk utilitas CLI, skrip otomatisasi, dan lainnya di sistem mirip Unix
• Jika diperlukan, aplikasi bisa diubah dengan mulus menjadi aplikasi berbasis proyek, sehingga alurnya natural dari belajar dan prototipe hingga pengembangan aplikasi yang sesungguhnya

---

Apa itu dotnet run app.cs

• Sebelumnya, untuk menjalankan kode C# dengan CLI dotnet, struktur proyek (.csproj) selalu dibutuhkan
• Kini, cukup dengan satu file .cs saja, kode bisa langsung dijalankan sehingga hambatan awal berkurang drastis
• Cocok untuk berbagai kebutuhan seperti bahasa skrip, otomatisasi, eksperimen, dan pembelajaran
• Berkat integrasi CLI, cukup punya dotnet tanpa perlu memasang alat tambahan
• Jika kode membesar, aplikasi dapat diperluas menjadi aplikasi berbasis proyek dengan bahasa dan tool yang sama

Dukungan directive tingkat file

• Pada aplikasi berbasis file, pengaturan penting proyek juga bisa langsung dideklarasikan sebagai directive di dalam file .cs

• Referensi paket NuGet

  • Dengan directive #:package, paket NuGet bisa langsung direferensikan
    • Contoh:

      #: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.");  
      

• Menentukan SDK

  • Dengan directive #:sdk, jenis SDK dapat ditentukan
    • Contoh:

      #:sdk Microsoft.NET.Sdk.Web  
      

    • Fitur ASP.NET Core (minimal API, MVC, dll.) juga dapat diaktifkan

• Mengatur properti MSBuild

  • Dengan #:property, properti build bisa ditentukan secara langsung
    • Contoh:

      #:property LangVersion preview  
      

• Dukungan shebang untuk skrip shell

  • Tambahkan #!/usr/bin/dotnet run di baris paling atas file agar bisa langsung dipakai sebagai file eksekusi di sistem mirip Unix
    • Contoh:

      #!/usr/bin/dotnet run  
      Console.WriteLine("Hello from a C# script!");  
      

    • Setelah memberi izin eksekusi, jalankan langsung:

      chmod +x app.cs  
      ./app.cs  
      

Konversi ke aplikasi berbasis proyek

• Saat aplikasi membesar atau memerlukan fitur tambahan, Anda dapat dengan mudah mengubahnya menjadi proyek dengan perintah dotnet project convert app.cs
• Directive akan otomatis dikonversi menjadi properti .csproj, referensi, dan sebagainya

• Contoh konversi

  • File seperti berikut:

    #: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();  
    

• • Hasil konversi:

  <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>  
  

Perbedaan dengan pendekatan skrip C# sebelumnya

• Selama ini, eksekusi skrip C# memang dimungkinkan lewat tool komunitas seperti CS-Script, dotnet-script, Cake dan lainnya, tetapi memerlukan instalasi dan konfigurasi terpisah
• Kini, tanpa instalasi atau mode tambahan, Anda bisa langsung menjalankan kode dengan compiler dan bahasa C# yang sama tanpa hambatan awal

Cara memulai

• Instal .NET 10 Preview 4
• Jika menggunakan Visual Studio Code, perlu memasang C# Dev Kit dan ekstensi C# versi prarilis terbaru (2.79.8 atau lebih baru)
• Buat file .cs, lalu tulis kode langsung di dalamnya
• Jalankan dotnet run hello.cs di terminal
• Jika perlu, ubah menjadi proyek dengan dotnet project convert hello.cs

Pelajari lebih lanjut

• Demo sesi Microsoft Build: No projects, just C# with dotnet run app.cs

Rencana ke depan

• Dukungan aplikasi berbasis file di VS Code serta peningkatan IntelliSense untuk directive, performa, dan debugging akan ditambahkan
• Fitur tambahan seperti dukungan multi-file dan peningkatan kecepatan eksekusi juga sedang dikembangkan
• dotnet run app.cs membuat C# lebih mudah diakses sambil tetap menghadirkan kekuatan .NET sepenuhnya
• Menyediakan fondasi untuk beralih lebih cepat dari prototyping, pendidikan, hingga pengembangan produksi

[rkttu]

DX yang menyediakan pengalaman pelengkapan otomatis berbasis File-based App sudah tersedia di versi terbaru ekstensi C#, tetapi sebelumnya Microsoft tidak menerbitkan ekstensi tersebut di lokasi selain VS Code Marketplace.

Untuk mengatasi ketidaknyamanan ini, hanya bagian C# Extension dari C# Dev Kit (bagian berlisensi MIT) yang dibuat agar dapat di-autobuild/auto-publish secara terpisah lalu didaftarkan ke OpenVSX, dan saya membagikan video demo sederhana berbasis Kiro yang dibuat berdasarkan hal tersebut.

https://www.youtube.com/watch?v=pIi7CWOPQSA

[ndrgrd]

Saat sebelumnya saya menggunakan fitur C# Interactive, paket yang tidak terpasang secara lokal tidak bisa digunakan, tetapi sepertinya sekarang sudah diperbaiki.

[GN⁺]

Komentar Hacker News

• Fitur ini terasa seperti sesuatu yang bisa berdampak besar pada produktivitas developer .NET, jadi agak disayangkan juga, kenapa baru sekarang muncul. Dan ada satu hal yang benar-benar kuinginkan dari proyek .NET, yaitu kemampuan mendefinisikan custom command per proyek dengan mudah. Misalnya akan bagus kalau ada pola seperti npm run <command>
  • Aku memakai https://github.com/dotnet-script/dotnet-script tanpa masalah berarti, tapi tetap rasanya akan lebih baik kalau bisa melewati langkah-langkah yang merepotkan
  • Apa maksudmu sesuatu seperti https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run?
  • Kalau fitur seperti itu ada, akan sangat bagus. Untuk saat ini aku mengakalinya dengan makefile https://www.gnu.org/software/make/
  • Sebenarnya mungkin lebih baik memakai task runner terpisah seperti make atau task
  • Dulu aku pernah memakai LINQPad saat membutuhkan fitur seperti ini
• Menarik melihat ini dipromosikan untuk dipakai secara aktif bersama shebang. Pendekatan seperti ini terasa cukup menarik. Go juga dulu punya kegunaan scripting yang bagus dengan cara seperti ini bahkan sebelum modul diperkenalkan, dan kalau tidak salah Ubuntu juga pernah memakainya seperti itu. Tapi para penulis Go cenderung tidak mendukung penggunaan Go sebagai bahasa scripting seperti ini
  • Bukan berarti para penulis Go menentangnya, melainkan mereka menganjurkan agar Go dipakai terutama sebagai bahasa pemrograman. Dengan tool seperti gorun (https://github.com/erning/gorun), sejak lama Go sudah bisa dipakai seperti script dengan mudah. Belakangan ini juga didukung eksekusi langsung dengan menerima tag seperti go run github.com/kardianos/json/cmd/jsondiff@v1.0.1, dan itu fitur yang cukup keren
  • Aku penasaran sejak kapan dan dari mana istilah shebang dipakai. Saat kuliah dan di wilayah selatan pada era 90-an hingga awal 2000-an, orang biasanya menyebutnya hashbang. Aku baru pertama kali mendengar shebang saat C# mulai populer, padahal istilah itu sebenarnya sudah ada lebih lama, hanya saja aku belum pernah mendengarnya di sekitarku
  • Dulu saat bekerja di perusahaan .NET, pernah ada orang yang tiba-tiba menulis script automasi dengan bash. Tidak ada keahlian untuk memelihara script seperti itu dalam jangka panjang, dan kualitasnya juga buruk sejak awal. Aku benar-benar tidak paham kenapa mereka tidak langsung membuat tool-nya dalam C#. Dengan fitur ini, pendekatan C# mungkin akan terasa jauh lebih realistis sebagai alternatif
  • Hal seperti ini juga dimungkinkan dengan cargo milik Rust, hanya saja belum didukung secara resmi https://rust-lang.github.io/rfcs/3424-cargo-script.html
• Fitur ini sendiri bagus, tetapi bahkan dalam keadaan sudah terkompilasi pun startup overhead-nya sekitar 0,5 detik. Itu jadi kelemahan karena tidak cocok untuk banyak aplikasi. Meski begitu, shell scripting yang bergantung pada bash juga punya batasannya, era perl sudah lewat, dan Ruby masih yang terbaik untuk kegunaan seperti ini jadi aku tetap memakainya. Belakangan ini aku memindahkan beberapa script ke Swift, yang pada dasarnya bersifat interpreter sehingga jauh lebih cepat, dan executable hasil kompilasi bisa langsung dijalankan jadi sangat mengesankan. Aku bahkan sempat membuat compiler caching sendiri untuk aplikasi CLI Swift (https://github.com/jrz/tools). Sebagai catatan, dotnet run sendiri sudah meng-cache hasil kompilasi, jadi tidak perlu lapisan caching terpisah (untuk menonaktifkannya pakai --no-build, untuk melihat path binary pakai --artifacts-path)
  • Aku penasaran angka 0,5 detik itu berasal dari mana. Aku menguji hello world dan hasilnya 63ms. Kalau melihat benchmark library CLI buatan neuecc (https://neuecc.medium.com/consoleappframework-v5-zero-overhead-native-aot-compatible-cli-framework-for-c-8f496df8d9d1), tidak ada satu pun yang mencapai 0,5 detik. Sebagai tambahan, kamu menyebut Swift pada dasarnya interpreter, tetapi .NET JIT adalah tiered JIT, jadi kode tidak langsung dihasilkan sekaligus, melainkan melalui beberapa tahap
  • Aku dengar dotnet juga berencana menghadirkan mode interpreted penuh di versi 10 atau 11. Aku penasaran apakah mode itu akan diterapkan untuk penggunaan seperti ini https://github.com/dotnet/runtime/issues/112748
  • Kalau begitu, walaupun sudah dikompilasi masih ada sedikit lag saat startup, jadi aku penasaran kenapa python bisa sangat populer di ranah seperti ini
  • Fitur ini masih ada di tahap preview awal. Di beberapa presentasi juga sudah dijelaskan bahwa isu kecepatan startup ini sudah disadari dan sedang diperbaiki
  • Kalau ingin startup yang cepat, kamu bisa dengan mudah mengubahnya menjadi native code sesuai panduan https://learn.microsoft.com/en-us/dotnet/core/deploying/
• Agak disayangkan karena CSX/VBX hampir tidak disebut sama sekali https://ttu.github.io/dotnet-script/, dan menarik juga bahwa keputusan ini tampaknya dibuat dengan cara yang bahkan tidak kompatibel dengan penanganan dependensi script F# pada runtime C# https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/
  • Menanggapi soal upaya seperti CSX/VBX yang tidak tercermin, ada penjelasan bahwa secara resmi beberapa pendekatan dan tool memang disebutkan di sini https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#existing-ways-to-run-c#-without-projects
  • Aku ingin tahu maksud bagian yang disebut tidak kompatibel dengan F#. Kalau yang dimaksud adalah perbedaan sintaks, ada alasan memang sintaksnya sengaja dibuat berbeda, dan karena mereka tidak ingin membuat dialek script C# yang baru, fitur seperti import file sengaja dibatasi. Ini terkait dengan karakteristik C# itu sendiri
• Kotlin juga punya fitur serupa, https://github.com/Kotlin/kotlin-script-examples/blob/master/jvm/main-kts/MainKts.md (di sini ekstensi file harus *.main.kts agar berfungsi). Pendekatan seperti ini sangat bagus untuk script kecil atau prototyping, dan juga praktis untuk memanfaatkan fitur JVM. Meski begitu, untuk script kecil Ruby tetap yang paling nyaman, terutama karena sintaks backtick untuk menjalankan program eksternal benar-benar praktis
  • Kotlin scripting mungkin tidak akan benar-benar hilang, tetapi masa depannya tidak terlalu cerah https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-scripting-2024/
  • Seingatku Java sendiri juga sudah punya cara scripting yang mirip
• Dengan shebang, script C# bisa dijalankan seperti script bash https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#using-shebang-lines-for-shell-scripts
  • Aku mencoba shebang pada image sdk .net10 preview 4 untuk menjalankan file secara langsung, awalnya tidak berhasil. Dengan dotnet run <file> bisa jalan. Setelah update, semuanya normal. Penyebab masalahnya ternyata file memakai line ending CRLF, bukan LF
  • Senang sekali sekarang kita bisa menulis script dengan type safety. Sebagai catatan, di macOS kamu harus memakai #!/usr/local/share/dotnet/dotnet run atau #!/usr/bin/env -S dotnet run untuk shebang
• Ini terlihat seperti alat yang bisa menggantikan PowerShell. Ada kecenderungan PowerShell hampir dipakai seperti bahasa khusus ChatGPT. Di banyak perusahaan, script PowerShell memegang peran inti dalam infrastruktur, tetapi sering kali akhirnya jatuh ke kondisi yang praktis hanya-baca
  • Rasanya ini punya potensi menggantikan jauh lebih banyak dari sekadar PowerShell. Kalau timnya memang tim .NET, mereka tak perlu repot menyentuh Python atau shell script; cukup tambahkan shebang di bagian atas lalu tempel snippet C#, dan hampir semua kebutuhan scripting bisa ditangani. Bahkan untuk service uji pun tak perlu membuatnya dengan express.js, cukup bikin cepat dengan ASP.NET minimal API
  • Mungkin administrator sistem Windows adalah kelompok pengguna script buatan ChatGPT terbesar. Kalau aku masih jadi admin seperti dulu, dengan mempertimbangkan kualitas dokumentasi resmi MS, sepertinya aku pasti akan memakainya
  • Kode C# juga bisa dipanggil dari PowerShell https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/add-type?view=powershell-7.5
  • Menaruh seluruh infrastruktur ke dalam script PowerShell sebenarnya tidak mudah, dan kalau dipaksakan hasilnya hanya akan jadi kekacauan total. Dalam praktiknya, begitu melewati beberapa fungsi saja, C# jauh lebih efisien dan hambatan masuknya pun nyaris tidak ada. PowerShell ideal untuk script ad-hoc kecil, dan pada dasarnya menempati posisi seperti VBScript dulu sebagai “bahasa script bawaan Windows”
  • Karena PowerShell bisa menjalankan kode .NET secara langsung, ada juga kesan bahwa pengalaman PowerShell justru jadi meluas
• Ini terasa seperti hampir menggantikan kemampuan NetPad, dan kalau debugging ditambahkan, mungkin LINQPad juga bisa mulai tersingkir dari penggunaan aktif. Dulu aku sangat terbantu oleh LINQPad, tetapi pengalaman text editor-nya sekarang terasa terlalu tidak nyaman untuk zaman ini. Ada batas yang jelas kalau dipakai untuk menulis atau mengedit kode secara serius
  • Bagiku, kegunaan utama LINQPad adalah interaksi dengan DB atau menjelajahi nilai dengan .dump(). dotnet run yang baru ini justru tampaknya bisa menjadi alat pelengkap untuk itu. Dulu aku pernah bekerja di tempat yang sangat membenci PowerShell, dan hampir semua scripting dilakukan dengan LINQPad. Dalam situasi seperti itu, ini bisa berguna
  • LINQPad adalah produk yang unik di ekosistem .NET, tetapi text editor-nya sendiri sering terasa mendekati yang terburuk sepanjang masa. Akan bagus kalau diganti dengan editor seperti neovim atau monaco. Visualisasi tabel dan snappiness-nya memang bagus, tetapi dibandingkan teknologi “notebook” modern seperti Jupyter Notebook, ruang pemakaiannya jadi lebih sempit. Mungkin juga karena dikembangkan sendirian. Meski begitu, untuk pekerjaan harian menyentuh data SQL, LINQPad tetap yang terbaik
  • Sepertinya LINQPad tidak akan langsung tergantikan. Menurutku setengah dari daya saingnya ada di UI. Aku penasaran seperti apa pengalaman memakai dotnet run di VSCode atau Visual Studio, dan seberapa mirip dengan LINQPad. Kekuatan LINQPad ada pada visualisasi hasil. Kalau dotnet run hanya menampilkan teks atau butuh banyak plugin tambahan, permintaan untuk LINQPad mungkin tetap ada. Kalau hanya perlu memeriksa sintaks dan semacamnya, dotnet run mungkin jadi pilihan yang lebih baik. Aku juga kadang menguji sintaks yang membingungkan di LINQPad
  • Kecuali semua fitur GUI dan extension point ikut diimplementasikan, akan sulit benar-benar menggantikan LINQPad secara langsung
• Aku benar-benar menantikan fitur ini. Sepertinya ini bisa menggantikan sebagian script PowerShell yang kupakai di pipeline CI/CD. Aku suka PowerShell maupun Bash, tetapi jelas ada pekerjaan yang jauh lebih efisien diselesaikan dalam bahasa bersintaks keluarga C di kepala. Fitur ini tampaknya bisa mengisi celah itu
• Proposal aslinya (https://github.com/dotnet/sdk/blob/main/documentation/general/dotnet-run-file.md) punya lebih banyak informasi, terutama soal penanganan banyak file dan detail implementasi seperti implicit project file

[rkttu]

Saya juga sudah membuat dua contoh nyata terkait fitur ini, jadi saya bagikan sebagai balasan. Ini adalah kode sampel aplikasi GUI Windows dan macOS yang menggunakan server MCP dan Avalonia. 😊

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