go.win-arm64

What is go#?

go# (go sharp) lets you run .cs files directly, like scripts, while still getting the full power of the .NET SDK (dependencies, compilation, AOT, etc.).

It shines for:

• Quick one-off tools and prototypes
• File-based apps without a .csproj
• Fast iteration with smart caching (subsequent runs are near-instant when nothing changed)
• Easy sharing of small utilities (just a .cs file or a remote ref like owner/repo[@ref][:path])

Usage

# Run a file
dnx go app.cs

# Pass arguments to your app
dnx go app.cs -- arg1 arg2

# Pass arguments to the underlying `dotnet publish`
dnx go app.cs /p:MyProp=true -- arg1 arg2

The default mode publishes the app with native AOT and then runs the resulting executable, with smart up-to-date checks of every C# file used to build the app (including #include and #ref directives, transitively).

Use --r2r when your app needs more dynamic .NET features (reflection, dynamic loading, etc.) that native AOT does not support, while still keeping most publish optimizations:

dnx go app.cs --r2r

# Pass arguments to your app
dnx go app.cs --r2r -- arg1 arg2

This publishes with /p:PublishAot=false and /p:PublishReadyToRun=true. An equivalent --aot switch is not needed since native AOT is the default for file-based apps.

A dev mode is also available for faster iteration, which skips the publish step and runs the app directly from the build output without the optimizations applied by dotnet to published executables (i.e. AOT, RID-specific optimizations):

dnx go dev app.cs

# Pass arguments to your app
dnx go dev app.cs -- arg1 arg2

# Pass arguments to the underlying `dotnet run`
dnx go dev app.cs /p:Configuration=Release -- arg1 arg2

Remote references

Instead of a local .cs file, you can pass a remote reference. The tool will download the content (when needed) and treat the resulting local file as the entry point:

# Run from a public repo (defaults to github.com, main + program.cs or first .cs)
dnx go kzu/sandbox

# Specific branch/tag and file
dnx go kzu/[email protected]:src/hello.cs

# Full host (GitHub, Gist, GitLab, Azure DevOps)
dnx go github.com/kzu/sandbox@main:hello.cs
dnx go gist.github.com/kzu/0ac826dc7de666546aaedd38e5965381
dnx go gitlab.com/kzu/runcs/-/blob/main/program.cs

The first argument is resolved by first checking if it is a local file (File.Exists). If not, it falls back to parsing it as a remote ref (owner/repo[@ref][:path]).

Downloaded content is cached under the dotnet/go directory (same root as local apps) and participates in the normal up-to-date checks. Remote refs are always revalidated by sending a conditional request (using ETag when available) to the source. A 304 Not Modified response means the local copy is used as-is.

To force a fresh download for a remote ref, clean its bundle first:

# Clean the downloaded bundle for a remote ref (forces full download on next run)
dnx go clean kzu/sandbox

# Works for refs with @ref or :path too (the bundle for the ref is deleted entirely)
dnx go clean kzu/sandbox@main:program.cs

The go-specific switches support both bare and --go- prefixed forms for consistency:

• --debug / --go-debug
• --r2r / --go-r2r

Behavior follows the chosen command:

• Default command: downloads (if needed) then dotnet publish + execute (AOT by default).
• dev command: downloads (if needed) then dotnet run for fast iteration.

Arguments after -- (or all trailing args) are forwarded exactly as with local files.

Cache and cleaning

go# caches build and publish outputs per entry-point file under the user's temp area (%TEMP%\dotnet\go on Windows, ~/.local/share/dotnet/go on Linux, ~/Library/Application Support/dotnet/go on macOS), which is what makes unchanged re-runs near-instant.

# Delete the cached artifacts for a single app (next run rebuilds)
dnx go clean app.cs

# Delete the downloaded bundle for a remote ref (next run re-downloads; :path ignored)
dnx go clean owner/repo[@ref][:path]

# Delete the cached artifacts for all apps
dnx go clean --all

Unused download locations and published binaries are periodically cleaned up in a detached background process. Apps you run regularly are never affected.

Performance

The main advantage of go# is fast unchanged re-runs. The two core scenarios for go# file-based apps are:

• While tweaking 👉 dnx go dev app.cs (optimized dotnet run app.cs)
• When stable 👉 dnx go app.cs (optimized dotnet publish app.cs; app[.exe])

The numbers below showcase both scenarios, comparing go# to dotnet run and dotnet publish for a file-based app with different combinations of #include and #ref directives.

BenchmarkDotNet v0.15.8, Windows 11 (10.0.26200.8737/25H2/2025Update/HudsonValley2)
AMD Ryzen AI 9 HX 370 w/ Radeon 890M 2.00GHz, 1 CPU, 24 logical and 12 physical cores
.NET SDK 11.0.100-preview.5.26302.115
  [Host]     : .NET 10.0.9 (10.0.9, 10.0.926.27113), X64 RyuJIT x86-64-v4
  Job-TASYDQ : .NET 10.0.9 (10.0.9, 10.0.926.27113), X64 RyuJIT x86-64-v4

InvocationCount=1  IterationCount=3  LaunchCount=1  
UnrollFactor=1  WarmupCount=1  

Open Source Maintenance Fee

To ensure the long-term sustainability of this project, users of this package who generate revenue must pay an Open Source Maintenance Fee. While the source code is freely available under the terms of the License, this package and other aspects of the project require adherence to the Maintenance Fee.

To pay the Maintenance Fee, become a Sponsor at the proper OSMF tier. A single fee covers all of Devlooped packages.

Sponsors

Learn more about GitHub Sponsors