Merge pull request #3040 from Mikejo5000/mikejo-br13

xplat work for MSBuild

Author: rjagiewich

docs/msbuild/build-loggers.md

@@ -37,25 +37,25 @@ Loggers provide a way for you to customize the output of your build and display
  [!code-csharp[msbuild_SimpleConsoleLogger#3](../msbuild/codesnippet/CSharp/build-loggers_2.cs)]  
 
 ## Respond to logger verbosity values  
- In some cases, you may want to only log information from an event if the MSBuild.exe **/verbosity** switch contains a certain value. In this example, the <xref:Microsoft.Build.Framework.IEventSource.TargetStarted> event handler only logs a message if the <xref:Microsoft.Build.Utilities.Logger.Verbosity%2A> property, which is set by the **/verbosity** switch, is equal to <xref:Microsoft.Build.Framework.LoggerVerbosity>`Detailed`.  
+ In some cases, you may want to only log information from an event if the MSBuild.exe **-verbosity** switch contains a certain value. In this example, the <xref:Microsoft.Build.Framework.IEventSource.TargetStarted> event handler only logs a message if the <xref:Microsoft.Build.Utilities.Logger.Verbosity%2A> property, which is set by the **-verbosity** switch, is equal to <xref:Microsoft.Build.Framework.LoggerVerbosity>`Detailed`.  
 
  [!code-csharp[msbuild_SimpleConsoleLogger#4](../msbuild/codesnippet/CSharp/build-loggers_3.cs)]  
 
 ## Specify a logger  
- Once the logger is compiled into an assembly, you need to tell [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] to use that logger during builds. This is done using the **/logger** switch with *MSBuild.exe*. For more information on the switches available for *MSBuild.exe*, see [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
+ Once the logger is compiled into an assembly, you need to tell [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] to use that logger during builds. This is done using the **-logger** switch with *MSBuild.exe*. For more information on the switches available for *MSBuild.exe*, see [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
 
- The following command line builds the project *MyProject.csproj* and uses the logger class implemented in *SimpleLogger.dll*. The **/nologo** switch hides the banner and copyright message and the **/noconsolelogger** switch disables the default [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] console logger.  
+ The following command line builds the project *MyProject.csproj* and uses the logger class implemented in *SimpleLogger.dll*. The **-nologo** switch hides the banner and copyright message and the **-noconsolelogger** switch disables the default [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] console logger.  
 
 ```cmd  
-MSBuild /nologo /noconsolelogger /logger:SimpleLogger.dll  
+MSBuild -nologo -noconsolelogger -logger:SimpleLogger.dll  
 ```  
 
  The following command line builds the project with the same logger, but with a `Verbosity` level of `Detailed`.  
 
 ```cmd  
-MSBuild /nologo /noconsolelogger /logger:SimpleLogger.dll /verbosity:Detailed  
+MSBuild -nologo -noconsolelogger -logger:SimpleLogger.dll -verbosity:Detailed  
 ```  
-  
+
 ## Example  
 
 ### Description  

docs/msbuild/building-multiple-projects-in-parallel-with-msbuild.md

@@ -18,28 +18,28 @@ ms.workload:
 # Build multiple projects in parallel with MSBuild
 You can use MSBuild to build multiple projects faster by running them in parallel. To run builds in parallel, you use the following settings on a multi-core or multiple processor computer:  
 
--   The `/maxcpucount` switch at a command prompt.  
+-   The `-maxcpucount` switch at a command prompt.  
 
 -   The <xref:Microsoft.Build.Tasks.MSBuild.BuildInParallel%2A> task parameter on an MSBuild task.  
 
 > [!NOTE]
->  The **/verbosity** (**/v**) switch in a command line can also affect build performance. Your build performance might decrease if the verbosity of your build log information is set to detailed or diagnostic, which are used for troubleshooting. For more information, see [Obtain build logs](../msbuild/obtaining-build-logs-with-msbuild.md) and [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
+>  The **-verbosity** (**-v**) switch in a command line can also affect build performance. Your build performance might decrease if the verbosity of your build log information is set to detailed or diagnostic, which are used for troubleshooting. For more information, see [Obtain build logs](../msbuild/obtaining-build-logs-with-msbuild.md) and [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
   
-## /maxcpucount Switch  
- If you use the `/maxcpucount` switch, or `/m` for short, MSBuild can create the specified number of *MSBuild.exe* processes that may be run in parallel. These processes are also known as "worker processes." Each worker process uses a separate core or processor, if any are available, to build a project at the same time as other available processors may be building other projects. For example, setting this switch to a value of "4" causes MSBuild to create four worker processes to build the project.  
+## -maxcpucount Switch  
+ If you use the `-maxcpucount` switch, or `-m` for short, MSBuild can create the specified number of *MSBuild.exe* processes that may be run in parallel. These processes are also known as "worker processes." Each worker process uses a separate core or processor, if any are available, to build a project at the same time as other available processors may be building other projects. For example, setting this switch to a value of "4" causes MSBuild to create four worker processes to build the project.  
 
- If you include the `/maxcpucount` switch without specifying a value, MSBuild will use up to the number of processors on the computer.  
+ If you include the `-maxcpucount` switch without specifying a value, MSBuild will use up to the number of processors on the computer.  
 
  For more information about this switch, which was introduced in MSBuild 3.5, see [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
 
  The following example instructs MSBuild to use three worker processes. If you use this configuration, MSBuild can build three projects at the same time.  
 
 ```cmd  
-msbuild.exe myproj.proj /maxcpucount:3   
+msbuild.exe myproj.proj -maxcpucount:3   
 ```  
-  
+
 ## BuildInParallel task parameter  
- `BuildInParallel` is an optional boolean parameter on a [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] task. When `BuildInParallel` is set to `true` (its default value is `false`), multiple worker processes are generated to build as many projects at the same time as possible. For this to work correctly, the `/maxcpucount` switch must be set to a value greater than 1, and the system must be at least dual-core or have two or more processors.  
+ `BuildInParallel` is an optional boolean parameter on a [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] task. When `BuildInParallel` is set to `true` (its default value is `false`), multiple worker processes are generated to build as many projects at the same time as possible. For this to work correctly, the `-maxcpucount` switch must be set to a value greater than 1, and the system must be at least dual-core or have two or more processors.  
 
  The following is an example, taken from *microsoft.common.targets*, about how to set the `BuildInParallel` parameter.  
 

docs/msbuild/common-msbuild-project-properties.md

@@ -42,14 +42,14 @@ The following table lists frequently used properties that are defined in the Vis
 |BaseOutputPath|Specifies the base path for the output file. If it is set, [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] will use `OutputPath = $(BaseOutputPath)\$(Configuration)\`. Example syntax: `<BaseOutputPath>c:\xyz\bin\</BaseOutputPath>`|  
 |BaseIntermediateOutputPath|The top-level folder where all configuration-specific intermediate output folders are created. The default value is `obj\`. The following code is an example: `<BaseIntermediateOutputPath>c:\xyz\obj\</BaseIntermediateOutputPath>`|  
 |BuildInParallel|A boolean value that indicates whether project references are built or cleaned in parallel when Multi-Proc [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] is used. The default value is `true`, which means that projects will be built in parallel if the system has multiple cores or processors.|  
-|BuildProjectReferences|A boolean value that indicates whether project references are built by [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)]. Automatically set to `false` if you are building your project in the [!INCLUDE[vsprvs](../code-quality/includes/vsprvs_md.md)] integrated development environment (IDE), `true` if otherwise. `/p:BuildProjectReferences=false` can be specified on the command line to avoid checking that referenced projects are up to date.|  
+|BuildProjectReferences|A boolean value that indicates whether project references are built by [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)]. Automatically set to `false` if you are building your project in the [!INCLUDE[vsprvs](../code-quality/includes/vsprvs_md.md)] integrated development environment (IDE), `true` if otherwise. `-p:BuildProjectReferences=false` can be specified on the command line to avoid checking that referenced projects are up to date.|  
 |CleanFile|The name of the file that will be used as the "clean cache." The clean cache is a list of generated files to be deleted during the cleaning operation. The file is put in the intermediate output path by the build process.<br /><br /> This property specifies only file names that do not have path information.|  
 |CodePage|Specifies the code page to use for all source-code files in the compilation. This property is equivalent to the `/codepage` compiler switch.|  
 |CompilerResponseFile|An optional response file that can be passed to the compiler tasks.|  
 |Configuration|The configuration that you are building, either "Debug" or "Release."|  
 |CscToolPath|The path of *csc.exe*, the [!INCLUDE[csprcs](../data-tools/includes/csprcs_md.md)] compiler.|  
 |CustomBeforeMicrosoftCommonTargets|The name of a project file or targets file that is to be imported automatically before the common targets import.|  
-|DebugSymbols|A boolean value that indicates whether symbols are generated by the build.<br /><br /> Setting **/p:DebugSymbols=false** on the command line disables generation of program database (*.pdb*) symbol files.|  
+|DebugSymbols|A boolean value that indicates whether symbols are generated by the build.<br /><br /> Setting **-p:DebugSymbols=false** on the command line disables generation of program database (*.pdb*) symbol files.|  
 |DefineConstants|Defines conditional compiler constants. Symbol/value pairs are separated by semicolons and are specified by using the following syntax:<br /><br /> *symbol1 = value1 ; symbol2 = value2*<br /><br /> The property is equivalent to the `/define` compiler switch.|  
 |DefineDebug|A boolean value that indicates whether you want the DEBUG constant defined.|  
 |DefineTrace|A boolean value that indicates whether you want the TRACE constant defined.|  

docs/msbuild/creating-forwarding-loggers.md

@@ -29,7 +29,7 @@ Forwarding loggers improve logging efficiency by letting you choose the events y
  In a multi-processor environment, event messages are likely to be received out of order. Therefore, you must evaluate the events by using the event handler in the forwarding logger and program it to determine which events to pass to the redirector for forwarding to the central logger. To accomplish this, you can use the <xref:Microsoft.Build.Framework.BuildEventContext> class, which is attached to every message, to help identify events you want to forward, and then pass the names of the events to the <xref:Microsoft.Build.BuildEngine.ConfigurableForwardingLogger> class (or a subclass of it). When you use this method, no other specific coding is required to forward events.  
 
 ## Specify a forwarding logger  
- After the forwarding logger has been compiled into an assembly, you must tell [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] to use it during builds. To do this, use the `/FileLogger`, `/FileLoggerParameters`, and `/DistributedFileLogger` switches together with *MSBuild.exe*. The `/FileLogger` switch tells *MSBuild.exe* that the logger is directly attached. The `/DistributedFileLogger` switch means that there is a log file per node. To set parameters on the forwarding logger, use the `/FileLoggerParameters` switch. For more information about these and other *MSBuild.exe* switches, see [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
+ After the forwarding logger has been compiled into an assembly, you must tell [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] to use it during builds. To do this, use the `-FileLogger`, `-FileLoggerParameters`, and `-DistributedFileLogger` switches together with *MSBuild.exe*. The `-FileLogger` switch tells *MSBuild.exe* that the logger is directly attached. The `-DistributedFileLogger` switch means that there is a log file per node. To set parameters on the forwarding logger, use the `-FileLoggerParameters` switch. For more information about these and other *MSBuild.exe* switches, see [Command-line reference](../msbuild/msbuild-command-line-reference.md).  
 
 ## Multi-processor-aware loggers  
  When you build a project on a multi-processor system, the build messages from each processor are not automatically interleaved in a unified sequence. Instead, you must establish a message grouping priority by using the <xref:Microsoft.Build.Framework.BuildEventContext> class that is attached to every message. For more information about multi-processor building, see [Logging in a multi-processor environment](../msbuild/logging-in-a-multi-processor-environment.md).  

docs/msbuild/how-to-build-specific-targets-in-solutions-by-using-msbuild-exe.md

@@ -22,13 +22,13 @@ You can use *MSBuild.exe* to build specific targets of specific projects in a so
 
 1.  At the command line, type `MSBuild.exe <SolutionName>.sln`, where `<SolutionName>` corresponds to the file name of the solution that contains the target that you want to execute.  
 
-2. Specify the target after the `/target:` switch in the format \<ProjectName>:\<TargetName>. If the project name contains any of the characters `%`, `$`, `@`, `;`, `.`, `(`, `)`, or `'`, replace them with an `_` in the specified target name.
+2. Specify the target after the `-target:` switch in the format \<ProjectName>:\<TargetName>. If the project name contains any of the characters `%`, `$`, `@`, `;`, `.`, `(`, `)`, or `'`, replace them with an `_` in the specified target name.
 
 ## Example  
  The following example executes the `Rebuild` target of the `NotInSlnFolder` project, and then executes the `Clean` target of the `InSolutionFolder` project, which is located in the *NewFolder* solution folder.  
 
 ```cmd
-msbuild SlnFolders.sln /target:NotInSlnfolder:Rebuild;NewFolder\InSolutionFolder:Clean
+msbuild SlnFolders.sln -target:NotInSlnfolder:Rebuild;NewFolder\InSolutionFolder:Clean
 ```
 
 ## Troubleshooting

docs/msbuild/how-to-build-the-same-source-files-with-different-options.md

@@ -44,34 +44,34 @@ When you build projects, you frequently compile the same components with differe
     ```  
 
 ## Specify properties on the command line  
- Once your project file is written to accept multiple configurations, you need to have the ability to change those configurations whenever you build your project. [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] provides this ability by allowing properties to be specified on the command line using the **/property** or **/p** switch.  
+ Once your project file is written to accept multiple configurations, you need to have the ability to change those configurations whenever you build your project. [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)] provides this ability by allowing properties to be specified on the command line using the **-property** or **-p** switch.  
 
 #### To set a project property at the command line  
 
--   Use the **/property** switch with the property and property value. For example:  
+-   Use the **-property** switch with the property and property value. For example:  
 
     ```cmd  
-    msbuild file.proj /property:Flavor=Debug  
+    msbuild file.proj -property:Flavor=Debug  
     ```  
 
     or  
 
     ```cmd  
-    Msbuild file.proj /p:Flavor=Debug  
+    Msbuild file.proj -p:Flavor=Debug  
     ```  
 
 #### To specify more than one project property at the command line  
 
--   Use the **/property** or **/p** switch multiple times with the property and property values, or use one **/property** or **/p** switch and separate multiple properties with semicolons (;). For example:  
+-   Use the **-property** or **-p** switch multiple times with the property and property values, or use one **-property** or **-p** switch and separate multiple properties with semicolons (;). For example:  
 
     ```cmd  
-    msbuild file.proj /p:Flavor=Debug;Platform=x86  
+    msbuild file.proj -p:Flavor=Debug;Platform=x86  
     ```  
 
     or
 
     ```cmd  
-    msbuild file.proj /p:Flavor=Debug /p:Platform=x86  
+    msbuild file.proj -p:Flavor=Debug -p:Platform=x86  
     ```  
 
  Environment variables are also treated as properties and are automatically incorporated by [!INCLUDE[vstecmsbuild](../extensibility/internals/includes/vstecmsbuild_md.md)]. For more information about using environment variables, see [How to: Use environment variables in a build](../msbuild/how-to-use-environment-variables-in-a-build.md).  
@@ -86,13 +86,13 @@ When you build projects, you frequently compile the same components with differe
  To build the debug version of this project, type:  
 
 ```cmd  
-msbuild consolehwcs1.proj /p:flavor=debug  
+msbuild consolehwcs1.proj -p:flavor=debug  
 ```  
 
  To build the retail version of this project, type:  
 
 ```cmd  
-msbuild consolehwcs1.proj /p:flavor=retail  
+msbuild consolehwcs1.proj -p:flavor=retail  
 ```  
 
 ```xml  
@@ -153,7 +153,7 @@ msbuild consolehwcs1.proj /p:flavor=retail
  To build the project, enter the following command:  
 
 ```cmd  
-msbuild colortest.proj /t:go /property:Color=Green  
+msbuild colortest.proj -t:go -property:Color=Green  
 ```  
 
 ```xml  

docs/msbuild/how-to-clean-a-build.md

@@ -47,13 +47,13 @@ When you clean a build, all intermediate and output files are deleted, leaving o
 ## Example  
  The following code example project contains a new target, `Clean`, that uses the `RemoveDir` task to delete a directory and all files and directories that it contains. Also in this example, the `Compile` target creates a separate directory for the output items that are deleted when the build is cleaned.  
 
- `Compile` is defined as the default target and is therefore used automatically unless you specify a different target or targets. You use the command line switch **/target** to specify a different target. For example:  
+ `Compile` is defined as the default target and is therefore used automatically unless you specify a different target or targets. You use the command line switch **-target** to specify a different target. For example:  
 
- `msbuild <file name>.proj /target:Clean`  
+ `msbuild <file name>.proj -target:Clean`  
 
- The **/target** switch can be shortened to **/t** and can specify more than one target. For example, to use the target `Clean` then the target `Compile`, type:  
+ The **-target** switch can be shortened to **-t** and can specify more than one target. For example, to use the target `Clean` then the target `Compile`, type:  
 
- `msbuild <file name>.proj /t:Clean;Compile`  
+ `msbuild <file name>.proj -t:Clean;Compile`  
 
 ```xml  
 <Project DefaultTargets = "Compile"