dotnet-build - Man Page

Builds a project and all of its dependencies.

Examples (TL;DR)

dotnet build

This article applies to: ✓ .NET Core 1.x SDK and later versions

Synopsis

dotnet build [<PROJECT>|<SOLUTION>] [-c|--configuration] [-f|--framework] [--force]
    [--interactive] [--no-dependencies] [--no-incremental] [--no-restore] [--nologo] 
    [-o|--output] [-r|--runtime] [-v|--verbosity] [--version-suffix]

dotnet build [-h|--help]

Description

The dotnet build command builds the project and its dependencies into a set of binaries. The binaries include the project’s code in Intermediate Language (IL) files with a .dll extension. Depending on the project type and settings, other files may be included, such as:

For executable projects targeting versions earlier than .NET Core 3.0, library dependencies from NuGet are typically NOT copied to the output folder. They’re resolved from the NuGet global packages folder at run time. With that in mind, the product of dotnet build isn’t ready to be transferred to another machine to run. To create a version of the application that can be deployed, you need to publish it (for example, with the dotnet publish command). For more information, see .NET Core Application Deployment.

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

Building requires the project.assets.json file, which lists the dependencies of your application. The file is created when dotnet restore is executed. Without the assets file in place, the tooling can’t resolve reference assemblies, which results in errors. With .NET Core 1.x SDK, you needed to explicitly run dotnet restore before running dotnet build. Starting with .NET Core 2.0 SDK, dotnet restore runs implicitly when you run dotnet build. If you want to disable implicit restore when running the build command, you can pass the --no-restore option.

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.

MSBuild

dotnet build uses MSBuild to build the project, so 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.

Running dotnet build is equivalent to running dotnet msbuild -restore; however, the default verbosity of the output is different.

Arguments

PROJECT | SOLUTION

The project or solution file to build. If a project or solution file isn’t specified, MSBuild searches the current working directory for a file that has a file extension that ends in either proj or sln and uses that file.

Options

Examples

Info

.NET Core