18. 06. 2025 Francesco Belacca Microsoft

Dotnet Run App

Why am I writing this?

The recent introduction of file‐based apps in .NET 10 Preview 4 marks a turning point in how we think about C# for quick tasks and prototyping. With a single command—dotnet run app.cs—you can now execute a standalone C# file without ever creating a .csproj (May 28, 2025) devblogs.microsoft.com.

We also got a presentation of this during MS Build 2025: No projects just C# with `dotnet run app.cs` | DEM518 – YouTube

In this article, we’ll break down what this means, compare it head‐to‐head with PowerShell Core, and explore the strengths and weaknesses of each approach today—while casting a skeptical eye on where the two might collide or converge in the near future.

What’s New with `dotnet run app.cs`

Traditionally, running C# code with the dotnet CLI required scaffolding a project:

dotnet new console -n MyApp
cd MyApp
dotnet run

Now, with file-based apps you can drop that boilerplate:

dotnet run app.cs

Key points:

No .csproj needed: Great for tiny scripts, demos, educational experiments.
Same runtime, same compiler: This isn’t a stripped-down dialect; it leverages the full .NET 10 SDK under the hood.
File-level directives: You can reference NuGet packages (#:package), change SDK (#:sdk), and even declare MSBuild properties (#:property) directly in your .cs file devblogs.microsoft.com.
Shebang (Unix) support: Unix-style scripts with #! work out of the box, so chmod +x app.cs && ./app.cs feels native.

PowerShell Core: The Established Scripting Powerhouse

PowerShell, originally Windows-only, went open-source and cross-platform on August 18, 2016, as PowerShell Core, running on .NET Core – en.wikipedia.org.

Today’s PowerShell:

Implementation: Written in C# on top of .NET (formerly .NET Core).
Object pipeline: Cmdlets emit rich .NET objects down the pipeline—no text parsing required.
Interactive REPL and scripting: A mature environment for both ad-hoc and complex automation.
Cross-platform consistency: Same scripts run on Windows, Linux, and macOS.

Comparing the Two Worlds

Aspect	`dotnet run app.cs`	PowerShell Core
Startup	~Instant compile & run; for now it’s A LOT slower than PS (because it has to be compiled!) on startup but this may be negligible for most scripts	Startup is optimized, but remains slower than shells like Bash (though PS 7+ improved drastically)
Typing & Safety	Static, strong typing; compiler catches errors before runtime	Dynamic typing; flexible but prone to runtime errors
Dependency Management	Inline NuGet (`#:package`); same as full projects	PowerShell modules via `Install-Module`
Ecosystem	Full .NET libraries, LINQ, async/await	Vast repository of modules and cmdlets focused on administration
Interactive Editing	Limited REPL; relies on VS Code or IDE tooling and a recompile is needed every time anything changes	Built-in REPL, `Get-Help`, tab completion, `PSReadLine`
Use Case Fit	Algorithm prototyping, small APIs, demos	System administration, automation, orchestration

Let’s now do two simple examples.

If I want a simple and fast local echo api, It’s better if I use dotnet run and… it just works

I can then use a powershell command to get system informations, and send a simple post request to my dotnet api that is running locally:

You can find the code at: macel94/dotnetrunapp

You can spin up a codespace using the included devcontainer directly on github, so you won’t even need to clone the repo or install dependencies if you don’t want to.

So as you just saw, some things can be done easier using dotnet run, while other things can be easier using powershell core.

Future Convergence: A Skeptical Take

Given that PowerShell Core itself is implemented in C# on .NET, it’s only logical to expect deeper integration:

Shared engine improvements: As the .NET CLI evolves, PowerShell’s hosting APIs could leverage file-based app directives.
Unified scripting experience: Imagine pwsh run script.cs with compile-on-the-fly and full object pipeline.
Tooling harmony: VS Code extensions might blur the line between .cs and .ps1 files, offering cross-language IntelliSense and debugging, for maximum scripting efficiency to leverage .NET only for very complex parts, while maintaining pwsh as the orchestrator program for the glue between moving parts.

But let’s not drink the Kool-Aid just yet. Each tool has a distinct goal: .NET’s scripting is about C# exploration, while PowerShell focuses on administrative tasks.

I remain skeptical that one will fully subsume the other—at least not without significant reshaping of both ecosystems.

Conclusion

The arrival of dotnet run app.cs is a welcome nod to rapid C# scripting. It opens the door for C# in places we’ve traditionally defaulted to PowerShell—simple automation, lightweight tooling, quick demos. Yet, PowerShell Core’s object-oriented pipeline, interactive shell, and module ecosystem remain unmatched for system tasks. As these two converge under the .NET umbrella, expect interesting hybrids—but don’t discard the strengths that each tool brings to the table today.