dotnet-build(1)

πŸ“¦
version 11.0.0~rc3 Β· 6 versions
, in alpine 3.24, centos-stream 10, centos-stream 9, fedora 43, fedora 44, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

🌸 NAME 🌸

okay bestie, welcome to dotnet-build(1) from the .NET Documentation πŸ“–βœ¨ β€” this whole page applies to βœ”οΈ .NET 6 SDK and later versions, no cap.

dotnet-build β€” Builds a project, solution, or file-based app and all of its dependencies. that's the whole vibe πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

dotnet build [<PROJECT>|<SOLUTION>|<FILE>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--no-dependencies] [--no-incremental] [--no-restore] [--nologo]
    [--no-self-contained] [-o|--output <OUTPUT_DIRECTORY>] [--os <OS>]
    [-p|--property:<PROPERTYNAME>=<VALUE>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained] [--source <SOURCE>]
    [--tl:[auto|on|off]] [ --ucr|--use-current-runtime]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet build -h|--help

πŸ’… DESCRIPTION πŸ’…

so the dotnet build command builds the project, solution, or file-based app and its dependencies into a set of binaries. like it's giving assembly line but make it glamorous ✨

those binaries include the project's code in Intermediate Language (IL) files with a .dll extension. and depending on the project type and settings, other files may be included too, such as:

  • An executable that can be used to run the application. πŸƒβ€β™€οΈ
  • Symbol files used for debugging with a .pdb extension. πŸ”
  • A .deps.json file, which lists the dependencies of the application or library. πŸ“‹
  • A .runtimeconfig.json file, which specifies the shared runtime and its version for an application. βš™οΈ
  • Other libraries that the project depends on (via project references or NuGet package references). 🧩

for executable projects targeting .NET Core 3.0 and later, library dependencies are copied to the output folder. which means if there isn't any other publish-specific logic (such as Web projects have), the build output should be deployable. slay, deployable πŸ’–

🌈 Implicit restore 🌈

building requires the project.assets.json file, which lists the dependencies of your application. that file gets created when dotnet restore is executed. without the assets file in place, the tooling literally can't resolve reference assemblies, which results in errors. 😭 not the errors bestie.

you don't have to run dotnet restore though, 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.

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. iykyk ✨

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

πŸ‘‘ heads up: 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. so don't try it πŸ’€

πŸ¦‹ Executable or library output πŸ¦‹

whether the project is executable or not is determined by the <OutputType> property in the project file. the following example shows a project that produces executable code:

<PropertyGroup>
  <OutputType>Exe</OutputType>
</PropertyGroup>

to produce a library, omit the <OutputType> property or change its value to Library. the IL DLL for a library doesn't contain entry points and can't be executed. it's a library, it's not gonna run, that's not its job πŸ™ˆ

⭐ MSBuild ⭐

dotnet build uses MSBuild to build the project, solution, or file-based app. it supports both parallel and incremental builds. for more information, see Incremental Builds. πŸ“š

in addition to its options, the dotnet build command accepts MSBuild options, such as -p for setting properties or -l to define a logger. for more information about these options, see the MSBuild Command-Line Reference. or you can also use the dotnet msbuild command.

⚠️ when dotnet build is run automatically by dotnet run, arguments like -property:property=value aren't respected. fr fr, they get ignored 😀

running dotnet build is equivalent to running dotnet msbuild -restore; however, the default verbosity of the output is different. subtle but iconic πŸ’…

🧚 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. 🫢


πŸ’– ARGUMENTS πŸ’–

PROJECT | SOLUTION | FILE

the project or solution or C# (file-based app) file to operate on. if a file isn't specified, MSBuild searches the current directory for a project or solution. πŸ”Ž

  • PROJECT is the path and filename of a C#, F#, or Visual Basic project file, or the path to a directory that contains a C#, F#, or Visual Basic project file.
  • SOLUTION is the path and filename of a solution file (.sln or .slnx extension), or the path to a directory that contains a solution file.
  • FILE is an argument added in .NET 10. the path and filename of a file-based app. File-based apps are contained within a single file that is built and run without a corresponding project (.csproj) file. for more information, see Build file-based C# apps. 🌈

✨ OPTIONS ✨

okay bestie this is the big one, the whole menu of lil switches you can slap onto dotnet build πŸ’… every single one is here, no skips, let's go

  • -a, --arch <ARCHITECTURE> β€” tells it which architecture you're building for 🎯 it's a shorthand for setting the Runtime Identifier (RID), where your value gets smooshed together with the default RID. So like, on a win-x64 machine, passing --arch x86 sets the RID to win-x86. ⚠️ if you use this one, do not also use -r/--runtime. Available since .NET 6 Preview 7.
  • --artifacts-path <ARTIFACTS_DIR> β€” every build output file from the command you ran goes into subfolders under the path you give, split up by project πŸ“ (for more deets see Artifacts Output Layout). Available since .NET 8 SDK.
  • -c, --configuration <CONFIGURATION> β€” picks your build configuration 🌸 the default for most projects is Debug, but you can override the build configuration settings in your project.
  • --disable-build-servers β€” makes the command straight up ignore any persistent build servers 🚫 it's the consistent way to turn off all use of build caching, which forces a build from scratch. A build that doesn't lean on caches is a whole lifesaver when the caches might be corrupted or just plain wrong for some reason. Available since .NET 7 SDK.
  • -f, --framework <FRAMEWORK> β€” compiles for one specific framework πŸŽ€ and that framework must be defined in the project file. Examples: net7.0, net462.
  • --force β€” forces all dependencies to be resolved even if your last restore was a total success πŸ’ͺ specifying this flag is literally the same as deleting the project.assets.json file.
  • --interactive β€” lets the command stop and wait for you to input something or do an action πŸ™ˆ like completing authentication. Available since .NET Core 3.0 SDK.
  • --no-dependencies β€” ignores project-to-project (P2P) references and only builds the specified root project, nothing else βœ‚οΈ
  • --no-incremental β€” marks the build as unsafe for incremental build 😀 this flag turns off incremental compilation and forces a clean rebuild of the project's dependency graph.
  • --no-restore β€” doesn't execute an implicit restore during build πŸ“
  • --nologo β€” doesn't display the startup banner or the copyright message 🀫
  • --no-self-contained β€” equivalent to --self-contained false.
  • -o, --output <OUTPUT_DIRECTORY> β€” the directory where the built binaries go πŸ“¦ if you don't specify it, the default path is ./bin/<configuration>/<framework>/. For projects with multiple target frameworks (via the TargetFrameworks property), you also need to define --framework when you specify this option.
    • .NET 7.0.200 SDK and later If you specify the --output option when running this command on a solution, the CLI will emit a warning (an error in 7.0.200) due to the unclear semantics of the output path 😭 the --output option is disallowed because all outputs of all built projects would be copied into the specified directory, which isn't compatible with multi-targeted projects, as well as projects that have different versions of direct and transitive dependencies. For more information, see Solution-level --output option no longer valid for build-related commands.
  • --os <OS> β€” specifies the target operating system (OS) 🌈 this is a shorthand syntax for setting the Runtime Identifier (RID), where the value you give is combined with the default RID. Like, on a win-x64 machine, passing --os linux sets the RID to linux-x64. ⚠️ if you use this option, don't use the -r/--runtime option. Available since .NET 6.
  • -p, --property:<PROPERTYNAME>=<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>
  • -r, --runtime <RUNTIME_IDENTIFIER> β€” specifies the target runtime πŸƒ for a list of Runtime Identifiers (RIDs), see the RID catalog. If you use this option with .NET 6 SDK, use --self-contained or --no-self-contained also. If not specified, the default is to build for the current OS and architecture.
  • --sc, --self-contained β€” publishes the .NET runtime with your application so the runtime doesn't need to be installed on the target machine 🫢 the default is true.
  • --source <SOURCE> β€” the URI of the NuGet package source to use during the restore operation πŸ”—
  • --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.

  • --ucr, --use-current-runtime β€” use the current runtime as the target runtime πŸ’œ
  • -v, --verbosity <LEVEL> β€” sets the verbosity level of the command πŸ“’ allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. For more information, see <xref:Microsoft.Build.Framework.LoggerVerbosity>.
  • --version-suffix <VERSION_SUFFIX> β€” sets the value of the $(VersionSuffix) property to use when building the project 🏷️ this only works if the $(Version) property isn't set. Then, $(Version) is set to the $(VersionPrefix) combined with the $(VersionSuffix), separated by a dash.
  • -?, -h, --help β€” prints out a description of how to use the command πŸ™‹β™€οΈ

🌸 EXAMPLES 🌸

okay now the fun part, real actual commands you can just copy and run, go off bestie πŸŽ€

  • Build a project and its dependencies:
dotnet build
  • Build a file-based app:
dotnet build MyProject.cs

File-based app support was added in .NET SDK 10.0.100. πŸ¦‹

  • Build a project and its dependencies using Release configuration:
dotnet build --configuration Release
  • Build a project and its dependencies for a specific runtime (in this example, Linux):
dotnet build --runtime linux-x64
  • Build the project and use the specified NuGet package source during the restore operation:
dotnet build --source c:\packages\mypackages
  • Build the project and set version 1.2.3.4 as a build parameter using the -p MSBuild option:
dotnet build -p:Version=1.2.3.4

and that's the whole page, you made it to the end ily πŸ₯ΉπŸ’– this lil manual lives in the dotnet-build(1) page, dated 2025-10-30, and you're officially the main character of your own build now. go compile something iconic, no cap πŸ’…βœ¨

πŸ“¦ where this page comes from