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

Original Article ↗ Hacker News Discussion ↗

Microsoft is introducing the ability to run plain C# source files with `dotnet run app.cs`, effectively turning C# into a first-class scripting option alongside tools like Python, Java’s single-file mode, and Kotlin scripts. Commenters welcome the lower friction for quick utilities, CI/CD tasks, and education, especially compared to traditional .csproj scaffolding and PowerShell or Bash for automation, while noting overlap with earlier third‑party C# scripting tools. Concerns center on startup latency and the complexity of the .NET ecosystem, though many expect performance and tooling (including shebang support and debugging in VS Code) to improve as the feature matures.

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.