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 saw 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 – all 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, and 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 this 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 highlight these with 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 information, and send a simple post request to my dotnet API that’s running locally:

You can find the code at: macel94/dotnetrunapp

You can spin up a code space 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 more easily using dotnet run, while other things can be are 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 a 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 .NET is leveraged 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, and 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.

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.