dotnet-run(1)

💖 dotnet-run(1) — the .NET docs, but make it make sense 💖

okay bestie, welcome to dotnet-run(1) from the .NET Documentation set 🎀 this is the page for the dotnet run command, and it applies to: ✔️ .NET 6 SDK and later versions. yes, 6 and up, if you're on something older this page is not your moment 😭

---

✨ NAME ✨

dotnet-run — Runs source code without any explicit compile or launch commands. it literally just does the thing for you 🫶

---

✨ SYNOPSIS ✨

dotnet run [<applicationArguments>]
  [-a|--arch <ARCHITECTURE>] [--artifacts-path <ARTIFACTS_DIR>]
  [-c|--configuration <CONFIGURATION>] [-e|--environment <KEY=VALUE>]
  [--file <FILE_PATH>] [-f|--framework <FRAMEWORK>] [--force] [--interactive]
  [--launch-profile <NAME>] [--no-build] [--no-dependencies]
  [--no-launch-profile] [--no-restore] [--os <OS>] [--project <PATH>]
  [-r|--runtime <RUNTIME_IDENTIFIER>] [--tl:[auto|on|off]]
  [-v|--verbosity <LEVEL>] [[--] [application arguments]]

dotnet run -h|--help

---

✨ DESCRIPTION ✨

so dotnet run is that girl 💅 she gives you a convenient option to run your application straight from the source code with just one command. it's lowkey perfect for fast iterative development from the command line. the way she works? she depends on the dotnet build command to build the code first. so every requirement that applies to the build also applies to dotnet run — no shortcuts, no exceptions, periodt.

🚨 heads up bestie: dotnet run doesn't respect arguments like /property:property=value, which are respected by dotnet build. so don't come crying to her with those, she will simply not see them 💀

Output files get written into the default location, which is bin/<configuration>/<target>. like, for example, if you have a netcoreapp2.1 application and you run dotnet run, the output is placed in bin/Debug/netcoreapp2.1. files are overwritten as needed (she's not sentimental 😭) and temporary files are placed in the obj directory.

If your project specifies multiple frameworks, running dotnet run results in an error unless you use the -f|--framework <FRAMEWORK> option to specify which framework you actually mean. she needs you to pick a lane 🦋

The dotnet run command is used in the context of projects, not built assemblies. so if you're trying to run a framework-dependent application DLL instead, you must use dotnet without a command. for example, to run myapp.dll, use:

dotnet myapp.dll

For more information on the dotnet driver, see .NET CLI overview. 👑

To run the application, the dotnet run command resolves the dependencies of the application that are outside of the shared runtime from the NuGet cache. and because it uses cached dependencies, it's not recommended to use dotnet run to run applications in production. instead, create a deployment using the dotnet publish command and deploy the published output. production is not her era, she's a dev-loop girlie 💅

---

🌸 Implicit restore 🌸

You don't have to run dotnet restore, bestie, because it's run implicitly by all commands that require a restore to occur, such as dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish, and dotnet pack. to disable implicit restore, use the --no-restore option. that's the off switch 🎀

The dotnet restore command is still useful in certain scenarios where explicitly restoring makes sense, like continuous integration builds in Azure DevOps Services, or in build systems that need to explicitly control when the restore occurs. so she's not useless, she's just situational ✨

For information about how to manage NuGet feeds, see the dotnet restore documentation.

This command supports the dotnet restore options when passed in the long form (for example, --source). short form options, such as -s, are not supported. long form or nothing, iykyk 🙈

---

🌈 Workload manifest downloads 🌈

When you run this command, it initiates an asynchronous background download of advertising manifests for workloads. if the download is still running when this command finishes, the download is stopped. for more information, see Advertising manifests. she starts it, she doesn't wait around for it 💀

---

✨ ARGUMENTS ✨

• <applicationArguments> — Arguments passed to the application that is being run.

Any arguments that aren't recognized by dotnet run are passed to the application. so like, she's generous, she'll forward them 🫶 but to separate arguments for dotnet run from arguments for the application, use the -- option. that little double-dash is the divider between "her business" and "your app's business" ⭐

---

to be continued... 🦋

✨ OPTIONS ✨

• -- — the lil fence between your args and the app's args 💖 Everything after this delimiter gets passed to the application being run. Not to dotnet run itself. Just the app. Okay bestie? periodt.
• -a, --arch <ARCHITECTURE> — sets the target architecture 🦋 This is a shorthand syntax for setting the Runtime Identifier (RID), where the value you give gets combined with the default RID. Like, on a win-x64 machine, specifying --arch x86 sets the RID to win-x86. If you use this option, do not also use -r|--runtime. Available since .NET 6 Preview 7 ✨
• --artifacts-path <ARTIFACTS_DIR> — all the build output files from the executed command go in subfolders under the path you specify, separated by project 🎀 For more info, see Artifacts Output Layout. Available since .NET 8 SDK.
• -c, --configuration <CONFIGURATION> — defines the build configuration 💅 The default for most projects is Debug, but you can override the build configuration settings in your project. Do your thing.
• --disable-build-servers — forces the command to ignore any persistent build servers 🙈 This gives you a consistent way to disable all use of build caching, which forces a build from scratch. A build that doesn't rely on caches is useful when the caches might be corrupted or incorrect for some reason. Available since .NET 7 SDK.
• -e, --environment <KEY=VALUE> — sets the specified environment variable in the process that will be run by the command 🌸 Important: the specified environment variable is not applied to the dotnet run process itself.

Environment variables passed through this option take precedence over ambient environment variables, System.CommandLine env directives, and environmentVariables from the chosen launch profile. For more information, see Environment variables.

This option was added in .NET SDK 9.0.200. Fresh off the press 💖

• -f, --framework <FRAMEWORK> — builds and runs the app using the specified framework 🧚 The framework must be specified in the project file, no cap.
• --file <FILE_PATH> — the path to the file-based app to run 👑 If a path isn't specified, the current directory is used to find and run the file. For more info on file-based apps, see Build file-based C# apps.

On Unix, you can run file-based apps directly, using the source file name on the command line instead of dotnet run. First, make sure the file has execute permissions. Then add a shebang line #! as the first line of the file, like:

#!/usr/bin/env dotnet run

Then you can run the file directly from the command line:

./ConsoleApp.cs

Introduced in .NET SDK 10.0.100 ✨

• --force — forces all dependencies to be resolved even if the last restore was successful 🔥 Specifying this flag is the same as deleting the project.assets.json file. Same energy, less typing.
• --interactive — allows the command to stop and wait for user input or action 💜 For example, to complete authentication. Available since .NET Core 3.0 SDK.
• --launch-profile <NAME> — the name of the launch profile (if any) to use when launching the application 🌈 Launch profiles are defined in the launchSettings.json file and are typically called Development, Staging, and Production. For more information, see Working with multiple environments.
• --no-build — doesn't build the project before running 🚫 It also implicitly sets the --no-restore flag. Two birds, one flag.
• --no-cache — skip up to date checks and always build the program before running 💀 No shortcuts. We build.
• --no-dependencies — when restoring a project with project-to-project (P2P) references, restores the root project and not the references 🙈
• --no-launch-profile — doesn't try to use launchSettings.json to configure the application 🌸
• --no-restore — doesn't execute an implicit restore when running the command ✨
• --no-self-contained — publish your application as a framework dependent application 💅 A compatible .NET runtime must be installed on the target machine to run your application.
• --os <OS> — specifies the target operating system (OS) 🦋 This is a shorthand syntax for setting the Runtime Identifier (RID), where the value you give gets combined with the default RID. Like, on a win-x64 machine, specifying --os linux sets the RID to linux-x64. If you use this option, do not also use -r|--runtime. Available since .NET 6.
• --project <PATH> — specifies the path of the project file to run (folder name or full path) 🎀 If not specified, it defaults to the current directory.

The -p abbreviation for --project is deprecated starting in .NET 6 SDK. For a limited time, -p can still be used for --project despite the deprecation warning. If the argument provided for the option doesn't contain =, the command accepts -p as short for --project. Otherwise, the command assumes that -p is short for --property. This flexible use of -p for --project will be phased out in .NET 7. We love a chaotic era but it's ending bestie 😭

• --property:<NAME>=<VALUE> — sets one or more MSBuild properties 👑

Specify multiple properties delimited by semicolons or by repeating the option:

--property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

The short form -p can be used for --property. If the argument provided for the option contains =, -p is accepted as short for --property. Otherwise, the command assumes that -p is short for --project.

To pass --property to the application rather than set an MSBuild property, provide the option after the -- syntax separator, for example:

dotnet run -- --property name=value

• -r, --runtime <RUNTIME_IDENTIFIER> — specifies the target runtime to restore packages for 🔥 For a list of Runtime Identifiers (RIDs), see the RID catalog.
• -sc, --self-contained — publishes the .NET runtime with your application so the runtime doesn't need to be installed on the target system 💖 The default is false. However, when targeting .NET 7 or lower, the default is true if a runtime identifier is specified. Sneaky little default, iykyk.
• --tl:[auto|on|off] — specifies whether Terminal Logger should be used for the build output 🌈 The default is auto, which first verifies the environment before enabling terminal logging. The environment check verifies that the terminal is capable of using modern output features and isn't using a redirected standard output before enabling the new logger. on skips the environment check and enables terminal logging. off skips the environment check and uses the default console logger.

Terminal Logger shows you the restore phase followed by the build phase 🎀 During each phase, the currently building projects appear at the bottom of the terminal. Each project that's building outputs both the MSBuild target currently being built and the amount of time spent on that target. You can search this information to learn more about the build. When a project is finished building, a single "build completed" section is written that captures:

• The name of the built project.
• The target framework (if multi-targeted).
• The status of that build.
• The primary output of that build (which is hyperlinked).
• Any diagnostics generated for that project.

This option is available starting in .NET 8 ⭐

• -v, --verbosity <LEVEL> — sets the verbosity level of the command 🦋 Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. The default is minimal. For more information, see <xref:Microsoft.Build.Framework.LoggerVerbosity>.
• -?, -h, --help — prints out a description of how to use the command 🫶 Your bestie when you forget literally everything.

---

🌈 ENVIRONMENT VARIABLES 🌈

There are four mechanisms by which environment variables can be applied to the launched application, and you're gonna learn all of them:

1. Ambient environment variables from the operating system when the command is run.
2. System.CommandLine env directives, like [env:key=value]. These apply to the entire dotnet run process, not just the project being run by dotnet run.
3. environmentVariables from the chosen launch profile (-lp) in the project's launchSettings.json file, if any. These apply to the project being run by dotnet run.
4. -e|--environment CLI option values (added in .NET SDK version 9.0.200). These apply to the project being run by dotnet run.

The environment is constructed in the same order as this list, so the -e|--environment option has the highest precedence 👑 Last one in wins, periodt.

---

💅 EXAMPLES 💅

• Run the project in the current directory:

dotnet run

• Run the specified file-based app in the current directory:

dotnet run --file ConsoleApp.cs

File-based app support was added in .NET SDK 10.0.100 ✨

• Run the specified project:

dotnet run --project ./projects/proj1/proj1.csproj

• Run the project in the current directory, specifying Release configuration:

dotnet run --property:Configuration=Release

• Run the project in the current directory (the --help argument in this example is passed to the application, since the blank -- option is used):

dotnet run --configuration Release -- --help

• Restore dependencies and tools for the project in the current directory only showing minimal output and then run the project:

dotnet run --verbosity m

• Run the project in the current directory using the specified framework and pass arguments to the application:

dotnet run -f net6.0 -- arg1 arg2

In the following example, three arguments are passed to the application 🌸 One argument is passed using -, and two arguments are passed after --:

dotnet run -f net6.0 -arg1 -- arg2 arg3

---

And that's the whole page bestie, you ate that 🍓 This one's from the dotnet-run(1) manual, dated 2025-10-30 — go forth and dotnet run something iconic 💖✨👑