MSBuild command-line reference
When you use MSBuild.exe to build a project or solution file, you can include several switches to specify various aspects of the process.
Every switch is available in two forms: -switch and /switch. The documentation only shows the -switch form. Switches are not case-sensitive. If you run MSBuild from a shell other than the Windows command prompt, lists of arguments to a switch (separated by semicolons or commas) might need single or double quotes to ensure that lists are passed to MSBuild instead of interpreted by the shell.
MSBuild.exe [Switches] [ProjectFile]
||Builds the targets in the project file that you specify. If you don't specify a project file, MSBuild searches the current working directory for a file name extension that ends in proj and uses that file. You can also specify a Visual Studio solution file for this argument.|
|-detailedSummary||-ds||Show detailed information at the end of the build log about the configurations that were built and how they were scheduled to nodes.|
||Causes MSBuild to construct and build a project graph. Constructing a graph involves identifying project references to form dependencies. Building that graph involves attempting to build project references prior to the projects that reference them, differing from traditional MSBuild scheduling. Requires MSBuild 16 or later.|
|-help||/? or -h||Display usage information. The following command is an example:
||Ignore the specified extensions when determining which project file to build. Use a semicolon or a comma to separate multiple extensions, as the following example shows:
||-||Indicates that actions in the build are allowed to interact with the user. Do not use this argument in an automated scenario where interactivity is not expected. Specifying -interactive is the same as specifying -interactive:true. Use the parameter to override a value that comes from a response file.|
||Causes MSBuild to build each project in isolation. This is a more restrictive mode of MSBuild as it requires that the project graph be statically discoverable at evaluation time, but can improve scheduling and reduce memory overhead when building a large set of projects.|
||Specifies the maximum number of concurrent processes to use when building. If you don't include this switch, the default value is 1. If you include this switch without specifying a value, MSBuild will use up to the number of processors in the computer. For more information, see Building multiple projects in parallel.
The following example instructs MSBuild to build using three MSBuild processes, which allows three projects to build at the same time:
|-noAutoResponse||-noautorsp||Don't include any MSBuild.rsp files automatically.|
||Enable or disable the re-use of MSBuild nodes. You can specify the following values:
- True. Nodes remain after the build finishes so that subsequent builds can use them (default).
- False. Nodes don't remain after the build completes.
A node corresponds to a project that's executing. If you include the -maxcpucount switch, multiple nodes can execute concurrently.
|-nologo||Don't display the startup banner or the copyright message.|
||Create a single, aggregated project file by inlining all the files that would be imported during a build, with their boundaries marked. You can use this switch to more easily determine which files are being imported, from where the files are being imported, and which files contribute to the build. When you use this switch, the project isn't built.
If you specify a
For information about how to use the
|-outputResultsCache[:cacheFile]||-orc[:cacheFile]||Output cache file where MSBuild will write the contents of its build result caches at the end of the build. Setting this also turns on isolated builds (-isolate).|
||-||Profiles MSBuild evaluation and writes the result to the specified file. If the extension of the specified file is '.md', the result is generated in Markdown format. Otherwise, a tab-separated file is produced.|
||Set or override the specified project-level properties, where
||Set or override these project-level properties only during restore and do not use properties specified with the -property argument.
||Build the specified targets in the project. Specify each target separately, or use a semicolon or comma to separate multiple targets, as the following example shows:
If you specify any targets by using this switch, they are run instead of any targets in the
A target is a group of tasks. For more information, see Targets.
||Write the list of available targets to the specified file (or the output device, if no file is specified), without actually executing the build process.|
||Specifies the version of the Toolset to use to build the project, as the following example shows:
By using this switch, you can build a project and specify a version that differs from the version that's specified in the Project element (MSBuild). For more information, see Overriding ToolsVersion settings.
For MSBuild 4.5, you can specify the following values for
A Toolset consists of tasks, targets, and tools that are used to build an application. The tools include compilers such as csc.exe and vbc.exe. For more information about Toolsets, see Toolset (ToolsVersion), Standard and custom toolset configurations, and Multitargeting. Note: The toolset version isn't the same as the target framework, which is the version of the .NET Framework on which a project is built to run. For more information, see Target framework and target platform.
||Validate the project file and, if validation succeeds, build the project.
If you don't specify
If you specify
The following setting is an example:
||Specifies the amount of information to display in the build log. Each logger displays events based on the verbosity level that you set for that logger.
You can specify the following verbosity levels:
The following setting is an example:
|-version||-ver||Display version information only. The project isn't built.|
||Insert command-line switches from a text file. If you have multiple files, you specify them separately. For more information, see Response files.|
||List of warning codes to treats as errors. Use a semicolon or a comma to separate multiple warning codes. To treat all warnings as errors, use the switch with no values. When a warning is treated as an error the target continues to execute as if it was a warning but the overall build fails.
||List of warning codes that should not be promoted to errors. Specifically, if the warnAsError switch is set to promote all warnings to errors, error codes specified with warnNotAsError are not promoted. This has no effect if warnAsError is not set to promote all warnings to errors. Use a semicolon or a comma to separate multiple warning codes.
||List of warning codes to treats as low importance messages. Use a semicolon or a comma to separate multiple warning codes.
Switches for loggers
|-bl||Serializes all build events to a compressed binary file. By default the file is in the current directory and named msbuild.binlog. The binary log is a detailed description of the build process that can later be used to reconstruct text logs and used by other analysis tools. A binary log is usually 10-20x smaller than the most detailed text diagnostic-level log, but it contains more information.
The binary logger by default collects the source text of project files, including all imported projects and target files encountered during the build. The optional
- ProjectImports=None. Don't collect the project imports.
- ProjectImports=Embed. Embed project imports in the log file (default).
- ProjectImports=ZipFile. Save project files to <output>.projectimports.zip where <output> is the same name as the binary log file name.
The default setting for ProjectImports is Embed.
Note: the logger does not collect non-MSBuild source files such as .cs, .cpp etc.
A .binlog file can be "played back" by passing it to msbuild.exe as an argument instead of a project/solution. Other loggers will receive the information contained in the log file as if the original build was happening. You can read more about the binary log and its usages at: https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md
||Pass the parameters that you specify to the console logger, which displays build information in the console window. You can specify the following parameters:
- PerformanceSummary. Show the time that's spent in tasks, targets, and projects.
- Summary. Show the error and warning summary at the end.
- NoSummary. Don't show the error and warning summary at the end.
- ErrorsOnly. Show only errors.
- WarningsOnly. Show only warnings.
- NoItemAndPropertyList. Don't show the list of items and properties that would appear at the start of each project build if the verbosity level is set to
- ShowCommandLine. Show
- ShowTimestamp. Show the timestamp as a prefix to any message.
- ShowEventId. Show the event ID for each started event, finished event, and message.
- ForceNoAlign. Don't align the text to the size of the console buffer.
- DisableConsoleColor. Use the default console colors for all logging messages.
- DisableMPLogging. Disable the multiprocessor logging style of output when running in non-multiprocessor mode.
- EnableMPLogging. Enable the multiprocessor logging style even when running in non-multiprocessor mode. This logging style is on by default.
- Verbosity. Override the -verbosity setting for this logger.
Use a semicolon to separate multiple parameters, as the following example shows:
The default console logger is at normal verbosity and includes a
|-distributedFileLogger||-dfl||Log the build output of each MSBuild node to its own file. The initial location for these files is the current directory. By default, the files are named MSBuild<NodeId>.log. You can use the -fileLoggerParameters switch to specify the location of the files and other parameters for the fileLogger.
If you name a log file by using the -fileLoggerParameters switch, the distributed logger will use that name as a template and append the node ID to that name when creating a log file for each node.
||Log events from MSBuild, attaching a different logger instance to each node. To specify multiple loggers, specify each logger separately.
You use the logger syntax to specify a logger. For the logger syntax, see the -logger switch below.
The following examples show how to use this switch:
||Log the build output to a single file in the current directory. If you don't specify
You can use the -fileLoggerParameters switch to specify the location of the file and other parameters for the fileLogger.
||Specifies any extra parameters for the file logger and the distributed file logger. The presence of this switch implies that the corresponding -filelogger[
You can use all parameters that are listed for -consoleloggerparameters. You can also use one or more of the following parameters:
- LogFile. The path to the log file into which the build log is written. The distributed file logger prefixes this path to the names of its log files.
- Append. Determines whether the build log is appended to the log file or overwrites it. When you set the switch, the build log is appended to the log file. When the switch is not present, the contents of an existing log file are overwritten.
If you include an explicit
In this case the file is overwritten:
In this case the file is appended:
In this case the file is appended:
- Encoding. Specifies the encoding for the file (for example, UTF-8, Unicode, or ASCII).
The following example generates separate log files for warnings and errors:
The following examples show other possibilities:
||Specifies the logger to use to log events from MSBuild. To specify multiple loggers, specify each logger separately.
Use the following syntax for
Use the following syntax for
You don't have to specify the logger class if the assembly contains exactly one logger.
Use the following syntax for
Logger parameters are optional and are passed to the logger exactly as you enter them.
The following examples use the -logger switch.
|-noConsoleLogger||-noconlog||Disable the default console logger, and don't log events to the console.|
The following example builds the
rebuild target of the MyProject.proj project.
MSBuild.exe MyProject.proj -t:rebuild
You can use MSBuild.exe to perform more complex builds. For example, you can use it to build specific targets of specific projects in a solution. The following example rebuilds the project
NotInSolutionFolder and cleans the project
InSolutionFolder, which is in the NewFolder solution folder.
msbuild SlnFolders.sln -t:NotInSolutionfolder:Rebuild;NewFolder\InSolutionFolder:Clean