dotnet-run - Man Page
Runs source code without any explicit compile or launch commands.
This article applies to: ✔️ .NET Core 3.1 SDK and later versions
dotnet run [-a|--arch <ARCHITECTURE>] [-c|--configuration <CONFIGURATION>] [-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>] [-v|--verbosity <LEVEL>] [[--] [application arguments]] dotnet run -h|--help
dotnet run command provides a convenient option to run your application from the source code with one command. It’s useful for fast iterative development from the command line. The command depends on the
dotnet build command to build the code. Any requirements for the build, such as that the project must be restored first, apply to
dotnet run as well.
dotnet run doesn’t respect arguments like
/property:property=value, which are respected by
Output files are written into the default location, which is
bin/<configuration>/<target>. 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. Temporary files are placed in the
If the project specifies multiple frameworks, executing
dotnet run results in an error unless the
-f|--framework <FRAMEWORK> option is used to specify the framework.
dotnet run command is used in the context of projects, not built assemblies. If you’re trying to run a framework-dependent application DLL instead, you must use dotnet without a command. For example, to run
For more information on the
dotnet driver, see the .NET Command Line Tools (CLI) topic.
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. 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.
You don’t have to run
dotnet restore because it’s run implicitly by all commands that require a restore to occur, such as
dotnet publish, and
dotnet pack. To disable implicit restore, use the
dotnet restore command is still useful in certain scenarios where explicitly restoring makes sense, such as continuous integration builds in Azure DevOps Services or in build systems that need to explicitly control when the restore occurs.
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.
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.
Delimits arguments to
dotnet runfrom arguments for the application being run. All arguments after this delimiter are passed to the application run.
Specifies the target architecture. This is a shorthand syntax for setting the Runtime Identifier (RID), where the provided value is combined with the default RID. For example, on a
--arch x86sets the RID to
win-x86. If you use this option, don’t use the
-r|--runtimeoption. Available since .NET 6 Preview 7.
Defines the build configuration. The default for most projects is
Debug, but you can override the build configuration settings in your project.
Builds and runs the app using the specified framework. The framework must be specified in the project file.
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.
Prints out a description of how to use the command.
Allows the command to stop and wait for user input or action. For example, to complete authentication. Available since .NET Core 3.0 SDK.
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
Production. For more information, see Working with multiple environments.
Doesn’t build the project before running. It also implicitly sets the
When restoring a project with project-to-project (P2P) references, restores the root project and not the references.
Doesn’t try to use launchSettings.json to configure the application.
Doesn’t execute an implicit restore when running the command.
Specifies the target operating system (OS). This is a shorthand syntax for setting the Runtime Identifier (RID), where the provided value is combined with the default RID. For example, on a
--os linuxsets the RID to
linux-x64. If you use this option, don’t use the
-r|--runtimeoption. Available since .NET 6.
Specifies the path of the project file to run (folder name or full path). If not specified, it defaults to the current directory.
--projectis deprecated starting in .NET 6 SDK. For a limited time starting in .NET 6 RC1 SDK,
-pcan still be used for
--projectdespite the deprecation warning. If the argument provided for the option doesn’t contain
=, the command accepts
-pas short for
--project. Otherwise, the command assumes that
-pis short for
--property. This flexible use of
--projectwill be phased out in .NET 7.
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
-pcan be used for
--property. If the argument provided for the option contains
-pis accepted as short for
--property. Otherwise, the command assumes that
-pis short for
--propertyto the application rather than set an MSBuild property, provide the option after the
--syntax separator, for example:
dotnet run -- --property name=value
Specifies the target runtime to restore packages for. For a list of Runtime Identifiers (RIDs), see the RID catalog.
Sets the verbosity level of the command. Allowed values are
diag[nostic]. The default is
minimal. For more information, see <xref:Microsoft.Build.Framework.LoggerVerbosity>.
Run the project in the current directory:
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
--helpargument 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