C# dosyalarını `dotnet run app.cs` ile doğrudan çalıştırma yöntemi

• .NET 10 Preview 4 ile birlikte artık tek bir C# dosyasını dotnet run app.cs ile doğrudan çalıştırmak mümkün; böylece proje dosyası olmadan da C# kodu çalıştırılabiliyor
• Dosya tabanlı uygulamalar (file-based apps) sayesinde Python veya JavaScript benzeri basit script çalıştırma, test etme ve fikir denemeleri çok daha kolay hale geliyor
• NuGet paket başvuruları, SDK belirleme, build özellikleri ayarlama gibi işlemler de dosya içindeki directive'lerle yönetilebildiği için geliştirme esnekliği artıyor
• shebang desteği sayesinde Unix tabanlı sistemlerde CLI yardımcı araçları ve otomasyon script'leri için de kullanılabiliyor
• Gerektiğinde proje tabanlı uygulamaya sorunsuz biçimde dönüştürülebilmesi, öğrenme ve prototiplemeden gerçek uygulama geliştirmeye doğal bir geçiş sağlıyor

---

dotnet run app.cs nedir?

• Daha önce dotnet CLI ile C# kodu çalıştırmak için mutlaka bir proje (.csproj) yapısı gerekiyordu
• Artık yalnızca tek bir .cs dosyasıyla doğrudan çalıştırma mümkün olduğu için giriş eşiği ciddi biçimde düşüyor
• Script dilleri, otomasyon, deneyler ve öğrenme gibi çeşitli kullanım senaryoları için uygun
• CLI entegrasyonu sayesinde ek araç kurmadan, yalnızca dotnet yüklüyse hemen kullanılabiliyor
• Kod büyüdüğünde aynı dil ve araçlarla proje tabanlı uygulamaya genişletilebiliyor

Dosya düzeyinde directive desteği

• Dosya tabanlı uygulamalarda da projenin temel ayarları doğrudan .cs dosyası içindeki directive'lerle tanımlanabiliyor

• NuGet paket başvurusu

  • #:package directive'i ile NuGet paketi doğrudan referanslanabiliyor
    • Örnek:

      #: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 belirleme

  • #:sdk directive'i ile SDK türü belirtilebiliyor
    • Örnek:

      #:sdk Microsoft.NET.Sdk.Web  
      

    • ASP.NET Core özellikleri de (minimal API, MVC vb.) etkinleştirilebiliyor

• MSBuild özellik ayarı

  • #:property ile build özellikleri doğrudan belirlenebiliyor
    • Örnek:

      #:property LangVersion preview  
      

• Shell script'leri için shebang desteği

  • Dosyanın en üstüne #!/usr/bin/dotnet run eklenerek Unix tabanlı sistemlerde yürütülebilir dosya olarak doğrudan kullanılabiliyor
    • Örnek:

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

    • Çalıştırma izni verildikten sonra doğrudan çalıştırma:

      chmod +x app.cs  
      ./app.cs  
      

Proje tabanlı uygulamaya dönüştürme

• Uygulama büyüdüğünde veya daha fazla özelliğe ihtiyaç duyulduğunda, dotnet project convert app.cs komutuyla kolayca projeye dönüştürülebiliyor
• Directive'ler otomatik olarak .csproj dosyasındaki özelliklere ve referanslara çevriliyor

• Dönüştürme örneği

  • Aşağıdaki gibi bir dosya:

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

• • Dönüştürme sonucu:

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

Mevcut C# script yaklaşımlarından farkı

• Şimdiye kadar C# script çalıştırmak için CS-Script, dotnet-script, Cake gibi topluluk araçları kullanılabiliyordu; ancak bunlar ayrı araç kurulumu ve ayar gerektiriyordu
• Artık ek kurulum veya ayrı bir mod olmadan aynı C# derleyicisi ve dili kullanılarak, giriş engeli olmaksızın doğrudan kod çalıştırılabiliyor

Nasıl başlanır

• .NET 10 Preview 4 kurun
• Visual Studio Code kullanıyorsanız C# Dev Kit ile C# eklentisinin en güncel ön sürümünü (2.79.8 veya üzeri) kurmanız gerekiyor
• Bir .cs dosyası oluşturup kodu yazın
• Terminalde dotnet run hello.cs komutunu çalıştırın
• Gerekirse dotnet project convert hello.cs ile projeye dönüştürün

Daha fazlası

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

Gelecek planları

• VS Code içinde dosya tabanlı uygulama desteği ve directive'ler için IntelliSense iyileştirmeleri, performans geliştirmeleri ve daha güçlü debug desteği planlanıyor
• Çoklu dosya desteği ve çalıştırma hızı iyileştirmeleri gibi ek özellikler de geliştiriliyor
• dotnet run app.cs, C#'ı daha erişilebilir hale getirirken .NET'in gücünü de aynen sunuyor
• Prototiplemeden eğitime ve production geliştirmeye daha hızlı geçiş için bir temel sağlıyor

[rkttu]

dotnet run app.cs ile C# dosyalarını doğrudan çalıştırma yöntemi

File-based App tabanlı otomatik tamamlama deneyimi sunan DX, C# eklentisinin en güncel sürümünde sağlanıyor; ancak başlangıçta Microsoft, eklentiyi VS Code Marketplace dışındaki bir yere yayımlamıyordu.

Bu tür bir rahatsızlığı gidermek için, C# Dev Kit yerine yalnızca C# Extension bölümünün (MIT lisanslı bölüm) ayrı olarak autobuild/auto-publish edilmesini sağlayıp OpenVSX'e kaydettim; buna dayanarak Kiro tabanlı basit bir demo videosu paylaşıyorum.

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

[ndrgrd]

Daha önce C# Interactive özelliğini kullandığımda yerel olarak kurulu olmayan paketleri kullanamıyordum; anlaşılan artık bu iyileştirilmiş.

[GN⁺]

Hacker News yorumu

• Bu özelliğin .NET geliştirici verimliliği üzerinde büyük etkisi olabilecek gibi görünmesi biraz hayıflandırıyor; neden ancak şimdi geldiğini merak ediyorum. Ayrıca .NET projelerinde gerçekten istediğim bir özellik daha var: proje bazında kolayca özel komutlar tanımlayabilmek. Örneğin npm run <command> benzeri bir yaklaşım olsa güzel olurdu.
  • Ben https://github.com/dotnet-script/dotnet-script kullanıyorum ve şimdiye kadar kayda değer bir sorun yaşamadım; yine de zahmetli adımları atlayabilmek daha da iyi olurdu.
  • Acaba https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run gibi bir şeyi mi kastediyorsunuz?
  • Böyle bir özellik gerçekten olsa harika olurdu; ben şu an bunu make dosyalarıyla çözüyorum https://www.gnu.org/software/make/
  • Aslında make ya da task gibi ayrı bir task runner kullanmak daha iyi bile olabilir.
  • Eskiden böyle bir şeye ihtiyaç duyduğumda LINQPad kullanmıştım.
• Bunu shebang ile birlikte aktif biçimde kullanmayı teşvik etmeleri ilginç; bu yaklaşım bana oldukça çekici geliyor. Go da modüller gelmeden önce bu şekilde scripting için kullanışlıydı diye hatırlıyorum, Ubuntu’nun da buna benzer kullanım örnekleri vardı. Ama Go yazarları, Go’nun bu tarz bir betik dili gibi kullanılmasına pek sıcak bakmıyordu.
  • Go yazarları karşı çıkmıyordu; daha çok Go’nun öncelikle bir programlama dili olarak kullanılmasını tavsiye ediyorlardı. gorun (https://github.com/erning/gorun) gibi araçlarla Go’yu uzun zamandır rahatça script gibi kullanmak mümkündü. Son dönemde ise go run github.com/kardianos/json/cmd/jsondiff@v1.0.1 gibi etiketleri doğrudan alıp tek seferde çalıştırmayı destekliyor; bu gerçekten hoş bir özellik.
  • “shebang” teriminin nereden ve ne zamandan beri kullanıldığını merak ediyorum. Üniversitedeyken ve 90’lar ile 2000’lerin başında güney bölgelerinde genelde hashbang denirdi. Shebang kelimesini ilk kez C# popülerleşirken duydum ama aslında daha eski bir terimmiş; sadece çevremde hiç rastlamamıştım.
  • Eskiden bir .NET şirketinde çalışırken birisi bir anda bash ile otomasyon script’leri yazmaya başlamıştı. Bu tür script’leri uzun vadede sürdürecek uzmanlık yoktu ve ilk yazıldıklarında da kaliteleri düşüktü. Neden aracın kendisini doğrudan C# ile yazmadıklarını anlayamamıştım. Bu özellik sayesinde C# yaklaşımı çok daha gerçekçi bir alternatif gibi hissedebilir.
  • Rust’ın cargo aracıyla da buna benzer bir şey yapılabiliyor, ama henüz resmi destek değil https://rust-lang.github.io/rfcs/3424-cargo-script.html
• Özelliğin kendisi harika ama derlenmiş olsa bile başlangıç yükü yaklaşık 0,5 saniye sürüyor; bu yüzden birçok uygulama için uygun olmama gibi bir dezavantajı var. Yine de bash tabanlı shell scripting’in sınırları var, perl dönemi geride kaldı ve Ruby bu tür işler için hâlâ en iyisi olduğu için kullanmaya devam ettim. Son zamanlarda bazı script’leri Swift’e taşıdım; varsayılan olarak yorumlayıcı tarzında çalıştığı için çok daha hızlı ve derlenmiş yürütülebilir dosyalar da anında çalıştığından oldukça etkileyici. Swift CLI uygulamaları için bir caching compiler bile yazdım (https://github.com/jrz/tools). Bu arada dotnet run zaten derleme çıktısını cache’lediği için ayrıca bir cache katmanına ihtiyaç yok (--no-build ile kapatılabilir, ikili dosya yolunu görmek için --artifacts-path kullanılabilir).
  • 0,5 saniye bilgisinin kaynağını merak ediyorum; ben hello world ile test ettim ve 63ms gördüm. neuecc’nin CLI kütüphanesi benchmark’ına (https://neuecc.medium.com/consoleappframework-v5-zero-overhead-native-aot-compatible-cli-framework-for-c-8f496df8d9d1) bakılırsa hiçbir şey 0,5 saniyeye ulaşmıyor. Ayrıca Swift’in varsayılan olarak yorumlayıcı tarzında çalıştığından bahsetmişsiniz ama .NET JIT, tiered JIT olduğu için kod tek seferde hemen üretilmiyor; birkaç aşamada ilerleyen bir yapısı var.
  • dotnet için 10 ya da 11 sürümünde tam yorumlanan bir mod geleceğini duydum; bunun bu tür kullanım senaryolarına uygulanıp uygulanmayacağını merak ediyorum https://github.com/dotnet/runtime/issues/112748
  • Derlenmiş olsa bile başlangıçta biraz gecikme oluyorsa, Python neden bu alanda bu kadar popüler oldu diye merak ediyorum.
  • Bu özellik hâlâ erken preview aşamasında; çeşitli sunumlarda başlangıç hızı sorununu bildiklerini ve iyileştirme üzerinde çalıştıklarını söylemişlerdi.
  • Hızlı başlangıç istiyorsanız, https://learn.microsoft.com/en-us/dotnet/core/deploying/ kılavuzundaki şekilde kolayca native koda dönüştürebilirsiniz.
• CSX/VBX projelerinden yeterince bahsedilmemesi biraz üzücü https://ttu.github.io/dotnet-script/. Ayrıca bunu, C# runtime’ında F# script’lerinin bağımlılık işleme biçimiyle de uyumlu olmayacak şekilde tasarlamış olmaları ilginç https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/
  • CSX/VBX gibi çabaların yansıtılmadığı yorumu için, aslında resmi olarak çeşitli yöntem ve araçların da anıldığını belirtmek gerekir https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#existing-ways-to-run-c#-without-projects
  • F# ile uyumsuzluk derken tam olarak ne kastedildiğini soruyorum. Eğer konu sözdizimi farkıysa, bunun kasıtlı bir tasarım amacı vardı ve ayrı bir C# script lehçesi yaratmak istemedikleri için dosya import gibi bazı şeyleri bilerek engelliyorlar; bu C#’ın doğasıyla ilgili.
• Kotlin’de de benzer bir özellik var: https://github.com/Kotlin/kotlin-script-examples/blob/master/jvm/main-kts/MainKts.md (burada çalışması için dosya uzantısının mutlaka *.main.kts olması gerekiyor). Bu yaklaşım küçük script’ler ve prototipleme için çok iyi, ayrıca JVM yeteneklerinden yararlanmak açısından da pratik. Yine de küçük script’lerde Ruby hâlâ en rahatı; özellikle dış program çalıştırırken backtick sözdizimi gerçekten çok kullanışlı.
  • Kotlin scripting tamamen yok olmayacak gibi görünüyor ama geleceği pek parlak değil https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-scripting-2024/
  • Bildiğim kadarıyla Java’nın kendisinde de benzer bir script çalıştırma yaklaşımı geldi.
• shebang kullanarak C# script’lerini bash script’i gibi çalıştırabiliyorsunuz https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/#using-shebang-lines-for-shell-scripts
  • .net10 preview 4 sdk imajında dosyayı doğrudan çalıştırmak için shebang test ettim ama ilk başta düzgün çalışmadı. dotnet run <file> ile ise çalışıyordu. Güncellemeden sonra düzeldi; sorunun nedeni dosyanın LF yerine CRLF satır sonları kullanmasıymış.
  • Artık type safety olan script’ler yazabilecek olmak çok sevindirici. Bu arada macOS’ta shebang olarak #!/usr/local/share/dotnet/dotnet run ya da #!/usr/bin/env -S dotnet run kullanmanız gerekiyor.
• PowerShell’in yerini alabilecek bir araç gibi görünüyor. PowerShell bazen neredeyse yalnızca ChatGPT için var olan bir dil gibi kullanılıyor. Birçok şirkette PowerShell ile yazılmış script’ler altyapının çekirdeğini oluşturuyor ama pratikte çoğu zaman “salt okunur” hale geliyor.
  • Yalnızca PowerShell’i değil, çok daha geniş bir alanı değiştirme potansiyeli var gibi görünüyor. Eğer bir .NET ekibiyseniz Python ya da shell script’lerine bulaşmadan, en üste bir shebang ekleyip C# snippet’leri yapıştırarak neredeyse tüm script işlerini çözebilirsiniz. Test servisleri için bile express.js ile bir şey yazmak yerine ASP.NET minimal API ile hızlıca halledilebilir.
  • Windows sistem yöneticileri muhtemelen en büyük ölçekte ChatGPT script kullanan topluluklardan biridir. Ben de eskiden yönetici olsaydım, MS resmi dokümantasyonunun seviyesini düşününce bunu kesin denerdim.
  • C# kodunu PowerShell içinden çağırmak da mümkün https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/add-type?view=powershell-7.5
  • Tüm altyapıyı PowerShell ile script’lemek pratikte o kadar kolay değil; öyle yapınca da tam bir kaos çıkıyor. Gerçekte birkaç fonksiyonu geçince C# çok daha verimli oluyor ve giriş engeli de neredeyse yok. PowerShell küçük, ad-hoc script’ler için mükemmel; eski VBScript’in sahip olduğu “Windows’un varsayılan betik dili” yerini dolduruyor.
  • PowerShell doğrudan .NET kodu çalıştırabildiği için, aslında PowerShell deneyimini genişleten bir yönü de var.
• Bu, NetPad işlevlerini fiilen ikame ediyor gibi ve sadece debugging eklenirse LINQPad’in de aktif kullanımda geri düşebileceği hissi var. Ben de zamanında LINQPad’den çok faydalandım ama metin editörü deneyimi günümüz için hâlâ fazla hantal. Ciddi kod yazımı ya da düzenleme için kullanmanın sınırları var.
  • Benim kullanımımda LINQPad’in ana gücü veritabanı etkileşimi ve .dump() ile değerleri keşfetmek. Bu yeni dotnet run ise daha çok onu tamamlayan bir araç gibi olabilir. Eskiden PowerShell’den aşırı nefret edilen bir yerde neredeyse tüm scripting işlerini LINQPad ile yapmıştık; böyle ortamlarda işe yarıyordu.
  • LINQPad .NET dünyasında benzersiz bir ürün ama metin editörü bazen tarihin en kötüleri arasında gibi hissettiriyor. Keşke neovim ya da monaco benzeri bir editörle değiştirilebilse. Tablo görselleştirme ve akıcılık çok iyi ama günümüzün Jupyter Notebook gibi “notebook” teknolojileriyle kıyaslayınca kullanım alanı daha dar kalıyor. Muhtemelen tek geliştiricili bir ürün olmasının da etkisi var. Yine de her gün işte SQL verisiyle uğraşırken LINQPad hâlâ bir numara.
  • LINQPad’in hemen yerini alacağını sanmıyorum; rekabet gücünün yarısı arayüzünde. VSCode ya da Visual Studio içinde dotnet run deneyiminin LINQPad’e ne kadar yaklaşacağını merak ediyorum. LINQPad’in gücü sonuçları görselleştirebilmesi. dotnet run yalnızca metin basıyorsa ya da çok sayıda ayrı eklenti gerektiriyorsa LINQPad’e ihtiyaç sürecektir. Yalnızca sözdizimini kontrol etmek gibi işler içinse dotnet run daha iyi bir tercih olabilir. Ben de ara sıra karıştırdığım sözdizimlerini LINQPad’de deneyerek kontrol ediyorum.
  • GUI işlevleri ve genişletme noktaları tamamen sağlanmadıkça LINQPad’i doğrudan ikame etmek zor görünüyor.
• Bu özelliği gerçekten heyecanla bekliyorum. CI/CD pipeline’larında kullandığım bazı PowerShell script’lerinin yerini alabilir gibi görünüyor. PowerShell’i de Bash’i de seviyorum ama kafada C benzeri sözdizimine sahip bir dille çözmek çok daha verimli olan işler kesinlikle var. Bu özellik o boşluğu doldurabilir.
• Asıl öneri metninde (https://github.com/dotnet/sdk/blob/main/documentation/general/dotnet-run-file.md) çok daha fazla bilgi var; özellikle çoklu dosya işleme ve uygulama ayrıntıları (örtük proje dosyaları gibi) hakkında daha detaylı açıklamalar içeriyor.

[rkttu]

Bu özellikle ilgili iki gerçek örnek de hazırladım, onları da yanıt olarak paylaşıyorum. MCP sunucusu ve Avalonia kullanılarak hazırlanmış Windows ve macOS GUI uygulaması örnek kodları. 😊

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