csharp-scripts

File-Based C# Apps

When to Use

• Testing a C# concept, API, or language feature with a quick file-based app
• Prototyping logic before integrating it into a larger project
• Building a small utility from one entry-point file and a few helper .cs files

When Not to Use

• The user asks for a language-agnostic quick script, throwaway computation, or shell/Python/PowerShell-style automation
• The user needs a full project, solution integration, or project references in an existing app
• The user is working inside an existing .NET solution and wants to add code there
• The app is large enough that project structure, build customization, tests, or publish configuration should live in a .csproj

Inputs

Workflow

Step 1: Check the .NET SDK version

Run dotnet --version to verify the SDK is installed and note the full version, including the feature band. File-based apps require .NET 10 or later. #:include, #:exclude, and transitive directive processing require SDK 10.0.300 or later; SDK 10.0.100/10.0.200 builds can run single-file apps but do not support those multi-file directives. If the version is below 10, follow the fallback for older SDKs instead.

Step 2: Write the app file

Create an entry-point .cs file using top-level statements. Place it outside any existing project directory to avoid conflicts with .csproj files.

#!/usr/bin/env dotnet
// hello.cs
Console.WriteLine("Hello from a file-based app!");
 
var numbers = new[] { 1, 

Guidelines:

• Use top-level statements (no Main method, class, or namespace boilerplate)
• Place using directives at the top of the file (after the #! line and any #: directives if present)
• Place type declarations (classes, records, enums) after all top-level statements

Step 3: Run the app

Builds and runs the file automatically. Cached so subsequent runs are fast. Pass arguments after --:

Step 4: Add directives (if needed)

Place directives at the top of the file (immediately after an optional shebang line), before any using directives or other C# code. All directives start with #:.

#:package — NuGet package references

Specify a version unless the app intentionally uses central package management. Use @* when the latest available package is acceptable (or @*-* for pre-release):

#:property — MSBuild properties

Set any MSBuild property inline. Syntax: #:property PropertyName=Value

MSBuild expressions and property functions are supported:

Common properties:

#:project — Project references

Reference another project by relative path:

#:ref — File-based app references

Reference another .cs file as a separate file-based app project when it should compile into a separate assembly instead of being included in the same compilation. Use #:include for ordinary helper files that should share the same assembly as the entry point; use #:ref when you want project-reference-like boundaries.

Guidelines:

• The referenced file is compiled as its own virtual project and added as a project reference.
• If the referenced file is a library without top-level statements, put #:property OutputType=Library in that referenced file.
• Members that must be consumed by the referencing app should be public; internal members are not visible across the assembly boundary.
• #:ref is transitive: a referenced file can contain its own #:ref and other #: directives.
• Relative paths are resolved relative to the file containing the directive.
• Some SDK builds require #:property ExperimentalFileBasedProgramEnableRefDirective=true; remove that property if the SDK accepts #:ref without it.

#:sdk — SDK selection

Override the default SDK (Microsoft.NET.Sdk):

#:include and #:exclude — Multi-file apps

In .NET SDK 10.0.300 and later, file-based apps can include additional files in the same virtual project. Check the full dotnet --version output before using these directives; a 10.0.100 or 10.0.200 SDK is still .NET 10 but does not support them. Use #:include for helper source files and supported assets, and #:exclude to remove files from an include pattern or default item set.

Guidelines:

• Treat the file passed to dotnet as the entry point; put top-level statements there.
• Put declarations such as classes, records, and enums in included .cs files.
• Prefer explicit globs such as Helpers.cs or Models/*.cs over broad recursive globs.
• Paths are resolved relative to the file containing the directive.
• Include directives from non-entry-point C# files are processed too, so a helper file can declare its own #:package, #:property, #:sdk, #:project, #:ref, #:include, or #:exclude directives.
• Avoid duplicate directives across included files unless the directive kind explicitly supports duplicates; duplicate #:package, #:property, #:sdk, #:include, and #:exclude entries can fail.
• When an app uses #:include, add a shebang (#!/usr/bin/env dotnet) to the entry-point file on Unix-like systems to make the entry point clear to tools. Use LF line endings and no BOM for shebang files.

Example layout:

Step 5: Clean up

Remove the app files when the user is done. To clear cached build artifacts:

Unix shebang support

On Unix platforms, make a .cs file directly executable:

1. Add a shebang as the first line of the file:

   #!/usr/bin/env dotnet
   Console.WriteLine("I'm executable!");

2. Set execute permissions:

   chmod +x hello.cs

3. Run directly:

   ./hello.cs

Use LF line endings (not CRLF) when adding a shebang. This directive is ignored on Windows.

Source-generated JSON

File-based apps enable native AOT by default. Reflection-based APIs like JsonSerializer.Serialize<T>(value) fail at runtime under AOT. Use source-generated serialization instead:

using System.Text.Json;
using System.Text.Json.Serialization;
 
var person = new Person("Alice", 30);
var json = JsonSerializer.Serialize(person, AppJsonContext.Default.Person);
Console.WriteLine(json);
 
var deserialized = JsonSerializer.Deserialize(json, AppJsonContext.Default.Person);
Console.WriteLine($"Name: {deserialized!.Name}, Age: {deserialized.Age}");
 
record Person(string Name, int Age);
 
[JsonSerializable(typeof(Person))]
partial class AppJsonContext : JsonSerializerContext;

Converting to a project

When a file-based app outgrows this workflow, convert it to a full project:

dotnet project convert hello.cs

Fallback for .NET 9 and earlier

If the .NET SDK version is below 10, file-based apps are not available. Use a temporary console project instead:

mkdir -p /tmp/csharp-file-based-app && cd /tmp/csharp-file-based-app
dotnet new console -o . --force

Replace the generated Program.cs with the app content and run with dotnet run. Add NuGet packages with dotnet add package <name>. Remove the directory when done.

Validation

• dotnet --version reports 10.0 or later (or fallback path is used)
• If the app uses #:include, #:exclude, or transitive directives from included files, dotnet --version reports SDK 10.0.300 or later
• The app compiles without errors (can be checked explicitly with dotnet build <file>.cs)
• dotnet <file>.cs produces the expected output
• Multi-file apps include every required helper file and exclude unintended matches
• App files and cached artifacts are cleaned up after the session

Common Pitfalls

More info

See https://learn.microsoft.com/en-us/dotnet/core/sdk/file-based-apps for a full reference on file-based apps.