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
.csfiles
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.
Guidelines:
- Use top-level statements (no
Mainmethod, class, or namespace boilerplate) - Place
usingdirectives 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=Libraryin that referenced file. - Members that must be consumed by the referencing app should be public; internal members are not visible across the assembly boundary.
#:refis transitive: a referenced file can contain its own#:refand 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#:refwithout 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
dotnetas the entry point; put top-level statements there. - Put declarations such as classes, records, and enums in included
.csfiles. - Prefer explicit globs such as
Helpers.csorModels/*.csover 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#:excludedirectives. - Avoid duplicate directives across included files unless the directive kind explicitly supports duplicates; duplicate
#:package,#:property,#:sdk,#:include, and#:excludeentries 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. UseLFline 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:
-
Add a shebang as the first line of the file:
-
Set execute permissions:
-
Run directly:
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:
Converting to a project
When a file-based app outgrows this workflow, convert it to a full project:
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:
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 --versionreports 10.0 or later (or fallback path is used) - If the app uses
#:include,#:exclude, or transitive directives from included files,dotnet --versionreports SDK 10.0.300 or later - The app compiles without errors (can be checked explicitly with
dotnet build <file>.cs) -
dotnet <file>.csproduces 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.


