Run a C# file directly using dotnet run app.cs

Original Article ↗ Hacker News Discussion ↗

Motivation & Developer Experience

  • Many see this as overdue but very welcome: it lowers friction for quick utilities, experimentation, CI/CD scripts, and “one-off” tools without scaffolding a project.
  • Top-level statements are widely viewed as having been added largely to enable this scripting-like workflow.
  • Some argue this is mainly beneficial inside existing .NET shops (replacing PowerShell, bash, or small Python tools), less as a way to win over non-.NET ecosystems.

Relation to Existing Tools & History

  • Commenters list a long history of similar approaches: CSI, .NET Interactive, csx/dotnet-script, LINQPad, cs-script, Mono’s interpreter, and third-party script runners for other languages (JBang for Java, Kotlin scripts, Rust/C/Go wrappers).
  • Several feel Microsoft’s announcement downplays prior community efforts; the blog was later updated to acknowledge them.
  • LINQPad is still valued for its UI and data visualization; this feature is seen as complementary rather than a full replacement.

Shebang, Directives, and Language Design

  • Shebang support is appreciated for making C# behave like a “real” shell scripting option (e.g., #!/usr/bin/env -S dotnet run).
  • New #:package/directive syntax for dependencies sparks debate: some want reuse of the existing #r style from F#/.NET Interactive; maintainers argue for clearer, non-opaque directives and no new “dialect.”
  • There is tension around .NET feeling like “C# Runtime” rather than a neutral CLR, and around perceived neglect of F# and VB.

Startup Performance & Implementation Concerns

  • Multiple measurements show dotnet run app.cs has noticeable startup overhead (hundreds of ms to >1s), even with caching; some say this makes it unsuitable for short-lived CLI tools.
  • Others note this is an early preview, with explicit plans to optimize, and that running the compiled binary directly is already much faster.
  • Comparisons are made with Python, Swift, Ruby, Perl, and Crystal; supporters say performance can be addressed via NativeAOT or precompilation, skeptics cite longstanding cold-start issues in .NET.

Ecosystem, Tooling, and Adoption

  • Some dislike csproj/MSBuild complexity and target framework confusion, though others argue modern SDK-style projects are much simpler.
  • There’s discussion of using C# scripting as a PowerShell replacement, but also strong defenses of PowerShell’s strengths and ecosystem.
  • Broader adoption is seen as constrained more by Microsoft’s ecosystem decisions and “stigma” than by scripting ergonomics alone.