MSBuild Command Line Reference
MSBuild.exe builds the specified project or solution file, with the specified options.
MSBuild.exe [Switches] [ProjectFile]
|
Switch |
Description |
|---|---|
|
/help |
Displays usage information. /? or /h are also acceptable. For example: Msbuild.exe /? |
|
/nologo |
Hides the startup banner and copyright message. |
|
/version |
Displays version information only. /ver is also acceptable. |
|
@file |
Inserts command line settings from a text file. Specify each response file separately. For more information, see MSBuild Response Files. |
|
/noautoresponse |
Does not auto-include the MSBuild.rsp file. /noautorsp is also acceptable. |
|
/target:targets |
Builds these targets in this project. Use a semicolon or a comma to separate multiple targets, or specify each target separately. /t is also acceptable. For example: /target:Resources;Compile |
|
/property:name=value |
Sets or overrides these project-level properties, where name is the property name and value is the property value. Use a semicolon or a comma to separate multiple properties, or specify each property separately. /p is also acceptable. For example: /property:WarningLevel=2;OutputDir=bin\Debug |
|
/logger:logger |
Specifies the logger to use to log events from MSBuild. To specify multiple loggers, specify each logger separately. The logger syntax is: [ LoggerClass ,] LoggerAssembly [; LoggerParameters ] The LoggerClass syntax is: [ PartialOrFullNamespace .] LoggerClassName NoteYou do not have to specify the logger class if there is exactly one logger in the assembly. The LoggerAssembly syntax is: { AssemblyName [, StrongName ] | AssemblyFile } Logger parameters are optional and are passed to the logger exactly as you type them. For example: /logger:XMLLogger,C:\Loggers\MyLogger.dll;OutputAsHTML |
|
/distributedlogger:<central logger>*<forwarding logger> |
Use this logger to log events from MSBuild. To specify multiple loggers, specify each logger separately. (Short form /dl) The <logger> syntax is: [<logger class>,]<logger assembly>[;<logger parameters>] The <logger class> syntax is: [<partial or full namespace>.]<logger class name> The <logger assembly> syntax is: {<assembly name>[,<strong name>] | <assembly file>} The <logger parameters> are optional, and are passed to the logger exactly as you typed them. (Short form: /l) Examples: /dl:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral /dl:MyLogger,C:\My.dll*ForwardingLogger,C:\Logger.dll |
|
/consoleloggerparameters:parameters |
Specifies the parameters to pass to the console logger. /clp is also acceptable. The available parameters are as follows:
|
|
/verbosity:level |
Displays this amount of information in the build log. Individual loggers display events based upon the verbosity level. A logger can also be configured to ignore the verbosity setting. The available verbosity levels are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. /v is also acceptable. For example: /verbosity:quiet |
|
/noconsolelogger |
Disables the default console logger and does not log events to the console. /noconlog is also acceptable. |
|
/validate:schema |
Validates the project file and, if validation succeeds, builds the project. If schema is not specified, validates the project against the default schema. If schema is specified, validates the project against the specified schema. |
|
/maxcpucount:number |
Specifies the number of worker processes that are involved in the build. For example: C:\Windows\WinFX\v3.5>msbuild.exe *.proj /maxcpucount:3. This example instructs MSBuild to build using three MSBuild.exe processes, thus allowing three projects to build in parallel. /m is also acceptable. |
|
/ignoreprojectextensions:<extensions> |
List of extensions to ignore when the project file to build is being determined. Use a semicolon or a comma to separate multiple extensions. (Short form: /ignore) Example: /ignoreprojectextensions:.vcproj,.sln |
|
/fileLogger |
Logs the build output to a single file ("msbuild.log") in the current directory. The location of the file and other parameters for the fileLogger can be specified through the addition of the "/fileLoggerParameters" switch. (Short form: /fl) |
|
/distributedFileLogger |
Logs the build output to multiple log files, one log file per MSBuild node. The initial location for these files is the current directory. By default the files are called "MSBuild<nodeid>.log". The location of the files and other parameters for the fileLogger can be specified with the addition of the "/fileLoggerParameters" switch. If a log file name is set through the fileLoggerParameters switch the distributed logger will use the fileName as a template and append the node id to this fileName to create a log file for each node. |
|
/fileloggerparameters:<parameters> |
Specifies the parameters for the file logger and distributed file logger. (Short form: /flp) You can use up to ten file loggers by following the parameter with a digit identifying the logger. For example, to generate separate log files for warnings and errors, use - /flp1:logfile=errors.txt;errorsonly /flp2:logfile=warnings.txt;warningsonly The available parameters are: LogFile - The path to the log file into which the build log is written. The distributed file logger uses this as a prefix for its log file names. Append - Determines if the build log is appended to or overwrite the log file. When you set the switch, the build log is appended to the log file. When you do not set the switch, the contents of an existing log file are overwritten. The default is not to append to the log file. Verbosity - Overrides the default verbosity setting of detailed. Encoding - specifies the encoding for the file, for example, UTF-8. Any of the console logger parameters can also be used. For example: /fileLoggerParameters:LogFile=MyLog.log;Append; Verbosity=diagnostic;Encoding=UTF-8 |
|
/toolsversion:version |
Specifies the version of the Toolset to use to build the project. This command lets you build a project by using a version different from that specified in the Project Element (MSBuild). For example: C:\Windows\WinFX\v3.5>msbuild.exe *.proj /ToolsVersion:3.5 /p:Configuration=Debug Valid values for version are as follows: 2.0, 3.0, and 3.5. For more information about Toolsets, see Building for Specific Versions of the .NET Framework. |
|
/nodeReuse:<parameters> |
Enables or Disables the re-use of MSBuild nodes. The parameters are: True - Nodes remain after the build completes and are reused by subsequent builds. False - Nodes do not remain after the build completes. (Short form: /nr) Example: /nr:true |
To pass parameters to the default console logger, first disable it with /noconsolelogger and then specify it with the /logger syntax. For example, use the following command line to show the performance summary ordinarily only displayed in diagnostic verbosity:
msbuild myproject.csproj /noconsolelogger /l:ConsoleLogger,Microsoft.Build.Engine.dll;performancesummary
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
Is there a list of all /p (parameters) and their possible values publishd somewhere for the MSBuild arguments?
Thanks
- 11/30/2011
- eliassal
I would be happy to know if there is away to execute a MSBuild CLI which will build different configurations (of the same solution) simultaneously, and will it have any effect on the overall processing time (in comparison to serial processing).
Something like: MSBuild.exe /property:Configuration1="Release English",Configuration2="Release Spanish" lang.sln
Thanks a lot!
- 8/18/2011
- ThePergl
- 4/19/2011
- nehabefrenz
Suppose you wish to build a specific solution configuration. These are listed in the solution file in the format as Debug|Win32, Release|All Platforms, etc. I originally thought that you would use /target to "target" the correct solution configuration to build. However, if you tried msbuild "SomeSolutionFile.sln" \t:"Debug|Win32" you will get the MSB4057 error that the target does not exist in the project.
Instead, you need to set the Configuration and Platform properties to the correct values: msbuild "SomeSolutionFile.sln" /p:Configuration=Debug /p:Platform=Win32
Your solution will then build as expected. The documentation above does not provide any hints or examples for this particular scenario.
So what are targets for anyway? If you set the MSBuildEmitSolution environment variable to "1" (thanks henny5225), and then look at the generated SomeSolutionFile.metaproj.tmp file after invoking msbuild, you will see the valid targets listed at the bottom. For my solution file these were defined as Build, Rebuild, Clean, and Publish. Looking at these, the /target switch seems to act more like a command instead of "building a target" as the documentation states.
- 3/18/2011
- AMP
- 2/17/2011
- Sergei Dorogin
MSBuild.exe MySolution.sln /t:MyProject.ContainsPeriodInName
You would get "error MSB4057" indicating that the target does not exist in the project (set the evironment variable MSBuildEmitSolution to "1" to have MSBuild write out the project file that it creates when building a solution).
If you examine the project file that MSBuild created you will see that the name of the project has been changed from "MyProject.ContainsPeriodInName" to "MyProject_ContainsPeriodInName". As you can see the period was changed to an underscore.
So, in order to build the project from the solution this is the command that you would use command:
MSBuild.exe MySolution.sln /t:MyProject_ContainsPeriodInName
It would be useful it this were documented...I couldn't find this information anywhere.
- 12/9/2010
- henny5225
- 11/3/2010
- WheresDaCode
<Path to Solution>\<Solution>.sln.metaproj : error MSB4057: The target "<Project Name>:<Target Name>" does not exist in the project.
This is probably because the .sln.metaproj is created in a way that excludes or leaves out custom targets in a project file. Additional information about how MSBuild creates the .sln.metaproj file would be helpful.
Test Note: tested with a .ccproj (Azure cloud computing project) with the same name as the solution. Probably need to verify this for other platforms/projects
- 9/29/2010
- J. Elster
<Path to Solution>\<Solution>.sln.metaproj : error MSB4057: The target "<Project Name>:<Target Name>" does not exist in the project.
This is probably because the .sln.metaproj is created in a way that excludes or leaves out custom targets in a project file. Additional information about how MSBuild creates the .sln.metaproj file would be helpful.
Test Note: tested with a .ccproj (Azure cloud computing project) with the same name as the solution. Probably need to verify this for other platforms/projects
- 9/29/2010
- J. Elster
Note