You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/msbuild/logging-in-a-multi-processor-environment.md
+10-10Lines changed: 10 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -14,16 +14,16 @@ manager: douge
14
14
ms.workload:
15
15
- "multiple"
16
16
---
17
-
# Logging in a Multi-Processor Environment
17
+
# Logging in a multi-processor environment
18
18
The ability of MSBuild to use multiple processors can greatly decrease project building time, but it also adds complexity to logging. In a single-processor environment, the logger can handle incoming events, messages, warnings, and errors in a predictable, sequential manner. However, in a multi-processor environment, events from several sources can arrive simultaneously or out of sequence. MSBuild provides a new multi-processor-aware logger and enables the creation of custom "forwarding loggers."
19
19
20
-
## Logging Multiple-Processor Builds
20
+
## Log multiple-processor builds
21
21
When you build one or more projects in a multi-processor or multi-core system, MSBuild build events for all the projects are generated simultaneously. An avalanche of event data may arrive at the logger at the same time or out of sequence. This can overwhelm the logger and cause increased build times, incorrect logger output, or even a broken build. To address these issues, the MSBuild logger can process out-of-sequence events and correlate events and their sources.
22
22
23
23
You can improve logging efficiency even more by creating a custom forwarding logger. A custom-forwarding logger acts as a filter by letting you choose, before you build, the events you want to monitor. When you use a custom forwarding logger, unwanted events do not overwhelm the logger, clutter your logs, or slow build times.
24
24
25
-
### Central Logging Model
26
-
For multi-processor builds, MSBuild uses a "central logging model." In the central logging model, an instance of MSBuild.exe acts as the primary build process, or "central node." Secondary instances of MSBuild.exe, or "secondary nodes," are attached to the central node. Any ILogger-based loggers attached to the central node are known as "central loggers" and loggers attached to secondary nodes are known as "secondary loggers."
25
+
### Central logging model
26
+
For multi-processor builds, MSBuild uses a "central logging model." In the central logging model, an instance of *MSBuild.exe* acts as the primary build process, or "central node." Secondary instances of *MSBuild.exe*, or "secondary nodes," are attached to the central node. Any ILogger-based loggers attached to the central node are known as "central loggers" and loggers attached to secondary nodes are known as "secondary loggers."
27
27
28
28
When a build occurs, the secondary loggers route their event traffic to the central loggers. Because events originate at several secondary nodes, the data arrives at the central node simultaneously but interleaved. To resolve event-to-project and event-to-target references, the event arguments include additional build event context information.
29
29
@@ -36,7 +36,7 @@ public interface INodeLogger: ILogger
36
36
}
37
37
```
38
38
39
-
### Distributed Logging Model
39
+
### Distributed logging model
40
40
In the central logging model, too much incoming message traffic, such as when many projects build at once, can overwhelm the central node, which stresses the system and lowers build performance.
41
41
42
42
To reduce this problem, MSBuild also enables a "distributed logging model" that extends the central logging model by letting you create forwarding loggers. A forwarding logger is attached to a secondary node and receives incoming build events from that node. The forwarding logger is just like a regular logger except that it can filter the events and then forward only the desired ones to the central node. This reduces the message traffic at the central node and therefore enables better performance.
@@ -53,9 +53,9 @@ public interface IForwardingLogger: INodeLogger
53
53
54
54
To forward events in a forwarding logger, call the <xref:Microsoft.Build.Framework.IEventRedirector.ForwardEvent%2A> method of the <xref:Microsoft.Build.Framework.IEventRedirector> interface. Pass the appropriate <xref:Microsoft.Build.Framework.BuildEventArgs>, or a derivative, as the parameter.
55
55
56
-
For more information, see [Creating Forwarding Loggers](../msbuild/creating-forwarding-loggers.md).
56
+
For more information, see [Create forwarding loggers](../msbuild/creating-forwarding-loggers.md).
57
57
58
-
### Attaching a Distributed Logger
58
+
### Attaching a distributed logger
59
59
To attaching a distributed logger on a command line build, use the `/distributedlogger` (or, `/dl` for short) switch. The format for specifying the names of the logger types and classes are the same as those for the `/logger` switch, except that a distributed logger is comprised of two logging classes: a forwarding logger and a central logger. Following is an example of attaching a distributed logger:
60
60
61
61
```cmd
@@ -66,6 +66,6 @@ Culture=neutral
66
66
67
67
An asterisk (*) separates the two logger names in the `/dl` switch.
Copy file name to clipboardExpand all lines: docs/msbuild/makedir-task.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ manager: douge
21
21
ms.workload:
22
22
- "multiple"
23
23
---
24
-
# MakeDir Task
24
+
# MakeDir task
25
25
Creates directories and, if necessary, any parent directories.
26
26
27
27
## Parameters
@@ -33,7 +33,7 @@ Creates directories and, if necessary, any parent directories.
33
33
|`DirectoriesCreated`|Optional <xref:Microsoft.Build.Framework.ITaskItem>`[]` output parameter.<br /><br /> The directories that are created by this task. If some directories could not be created, this may not contain all of the items that were passed into the `Directories` parameter.|
34
34
35
35
## Remarks
36
-
In addition to the parameters listed above, this task inherits parameters from the <xref:Microsoft.Build.Tasks.TaskExtension> class, which itself inherits from the <xref:Microsoft.Build.Utilities.Task> class. For a list of these additional parameters and their descriptions, see [TaskExtension Base Class](../msbuild/taskextension-base-class.md).
36
+
In addition to the parameters listed above, this task inherits parameters from the <xref:Microsoft.Build.Tasks.TaskExtension> class, which itself inherits from the <xref:Microsoft.Build.Utilities.Task> class. For a list of these additional parameters and their descriptions, see [TaskExtension base class](../msbuild/taskextension-base-class.md).
37
37
38
38
## Example
39
39
The following code example uses the `MakeDir` task to create the directory specified by the `OutputDirectory` property.
@@ -53,6 +53,6 @@ Creates directories and, if necessary, any parent directories.
Copy file name to clipboardExpand all lines: docs/msbuild/markupcompilepass1-task.md
+12-12Lines changed: 12 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -20,19 +20,19 @@ manager: douge
20
20
ms.workload:
21
21
- "multiple"
22
22
---
23
-
# MarkupCompilePass1 Task
23
+
# MarkupCompilePass1 task
24
24
25
25
The <xref:Microsoft.Build.Tasks.Windows.MarkupCompilePass1> task converts non-localizable [!INCLUDE[TLA#tla_xaml](../msbuild/includes/tlasharptla_xaml_md.md)] project files to compiled binary format.
26
26
27
-
## Task Parameters
27
+
## Task parameters
28
28
29
29
|Parameter|Description|
30
30
|---------------|-----------------|
31
31
|`AllGeneratedFiles`|Optional **ITaskItem[]** output parameter.<br /><br /> Contains a complete list of files that are generated by the <xref:Microsoft.Build.Tasks.Windows.MarkupCompilePass1> task.|
32
32
|`AlwaysCompileMarkupFilesInSeparateDomain`|Optional **Boolean** parameter.<br /><br /> Specifies whether to run the task in a separate <xref:System.AppDomain>. If this parameter returns **false**, the task runs in the same <xref:System.AppDomain> as [!INCLUDE[TLA#tla_msbuild](../msbuild/includes/tlasharptla_msbuild_md.md)] and it runs faster. If the parameter returns **true**, the task runs in a second <xref:System.AppDomain> that is isolated from [!INCLUDE[TLA2#tla_msbuild](../msbuild/includes/tla2sharptla_msbuild_md.md)] and runs slower.|
33
33
|`ApplicationMarkup`|Optional **ITaskItem[]** parameter.<br /><br /> Specifies the name of the application definition [!INCLUDE[TLA2#tla_xaml](../msbuild/includes/tla2sharptla_xaml_md.md)] file.|
34
34
|`AssembliesGeneratedDuringBuild`|Optional **String[]** parameter.<br /><br /> Specifies references to assemblies that change during the build process. For example, a Visual Studio solution may contain one project that references the compiled output of another project. In this case, the compiled output of the second project can be added to the **AssembliesGeneratedDuringBuild** parameter.<br /><br /> Note: The **AssembliesGeneratedDuringBuild** parameter must contain references to the complete set of assemblies that are generated by a build solution.|
35
-
|`AssemblyName`|Required **string** parameter.<br /><br /> Specifies the short name of the assembly that is generated for a project. For example, if a project is generating a [!INCLUDE[TLA#tla_mswin](../code-quality/includes/tlasharptla_mswin_md.md)] executable whose name is **WinExeAssembly.exe**, the **AssemblyName** parameter has a value of **WinExeAssembly**.|
35
+
|`AssemblyName`|Required **string** parameter.<br /><br /> Specifies the short name of the assembly that is generated for a project. For example, if a project is generating a [!INCLUDE[TLA#tla_mswin](../code-quality/includes/tlasharptla_mswin_md.md)] executable whose name is *WinExeAssembly.exe*, the **AssemblyName** parameter has a value of **WinExeAssembly**.|
36
36
|`AssemblyPublicKeyToken`|Optional **String** parameter.<br /><br /> Specifies the public key token for the assembly.|
37
37
|`AssemblyVersion`|Optional **String** parameter.<br /><br /> Specifies the version number of the assembly.|
38
38
|`ContentFiles`|Optional **ITaskItem[]** parameter.<br /><br /> Specifies the list of loose content files.|
@@ -44,7 +44,7 @@ The <xref:Microsoft.Build.Tasks.Windows.MarkupCompilePass1> task converts non-lo
44
44
|`HostInBrowser`|Optional **String** parameter.<br /><br /> Specifies whether the generated assembly is a [!INCLUDE[TLA#tla_xbap](../msbuild/includes/tlasharptla_xbap_md.md)]. The valid options are **true** and **false**. If **true**, code is generated to support browser hosting.|
45
45
|`KnownReferencePaths`|Optional **String[]** parameter.<br /><br /> Specifies references to assemblies that do not change during the build process. Includes assemblies that are located in the [!INCLUDE[TLA#tla_gac](../msbuild/includes/tlasharptla_gac_md.md)], in a [!INCLUDE[TLA#tla_netframewk](../misc/includes/tlasharptla_netframewk_md.md)] installation directory, and so on.|
46
46
|`Language`|Required **String** parameter.<br /><br /> Specifies the managed language that the compiler supports. The valid options are **C#**, **VB**, **JScript**, and **C++**.|
47
-
|`LanguageSourceExtension`|Optional **String** parameter.<br /><br /> Specifies the extension that is appended to the extension of the generated managed code file:<br /><br /> `<Filename>.g<LanguageSourceExtension>`<br /><br /> If the **LanguageSourceExtension** parameter is not set with a specific value, the default source file name extension for a language is used: **.vb** for [!INCLUDE[TLA#tla_visualb](../msbuild/includes/tlasharptla_visualb_md.md)], **.csharp** for [!INCLUDE[TLA#tla_cshrp](../data-tools/includes/tlasharptla_cshrp_md.md)].|
47
+
|`LanguageSourceExtension`|Optional **String** parameter.<br /><br /> Specifies the extension that is appended to the extension of the generated managed code file:<br /><br /> `<Filename>.g<LanguageSourceExtension>`<br /><br /> If the **LanguageSourceExtension** parameter is not set with a specific value, the default source file name extension for a language is used: *.vb* for [!INCLUDE[TLA#tla_visualb](../msbuild/includes/tlasharptla_visualb_md.md)], *.csharp* for [!INCLUDE[TLA#tla_cshrp](../data-tools/includes/tlasharptla_cshrp_md.md)].|
48
48
|`LocalizationDirectivesToLocFile`|Optional **String** parameter.<br /><br /> Specifies how to generate localization information for each source [!INCLUDE[TLA2#tla_xaml](../msbuild/includes/tla2sharptla_xaml_md.md)] file. The valid options are **None**, **CommentsOnly**, and **All**.|
49
49
|`OutputPath`|Required **String** parameter.<br /><br /> Specifies the directory in which the generated managed code files and [!INCLUDE[TLA2#tla_xaml](../msbuild/includes/tla2sharptla_xaml_md.md)] binary format files are generated.|
50
50
|`OutputType`|Required **String** parameter.<br /><br /> Specifies the type of assembly that is generated by a project. The valid options are **winexe**, **exe**, **library**, and **netmodule**.|
@@ -94,7 +94,7 @@ If any [!INCLUDE[TLA2#tla_xaml](../msbuild/includes/tla2sharptla_xaml_md.md)] fi
94
94
95
95
## Example
96
96
97
-
The following example shows how to convert three `Page`[!INCLUDE[TLA2#tla_xaml](../msbuild/includes/tla2sharptla_xaml_md.md)] files to binary format files. `Page1` contains a reference to a type, `Class1`, which is in the root namespace of the project and therefore, is not converted to binary format files in this markup compile pass. Instead, the [GenerateTemporaryTargetAssembly](../msbuild/generatetemporarytargetassembly-task.md) is executed and is followed by the [MarkupCompilePass2](../msbuild/markupcompilepass2-task.md).
97
+
The following example shows how to convert three *Page*[!INCLUDE[TLA2#tla_xaml](../msbuild/includes/tla2sharptla_xaml_md.md)] files to binary format files. *Page1* contains a reference to a type, `Class1`, which is in the root namespace of the project and therefore, is not converted to binary format files in this markup compile pass. Instead, the [GenerateTemporaryTargetAssembly](../msbuild/generatetemporarytargetassembly-task.md) is executed and is followed by the [MarkupCompilePass2](../msbuild/markupcompilepass2-task.md).
0 commit comments