Merge pull request #14107 from MicrosoftDocs/main

Auto Publish – main to live - 2025-07-23 22:30 UTC

Author: learn-build-service-prod[bot]

docs/extensibility/ux-guidelines/application-patterns-for-visual-studio.md

@@ -381,7 +381,8 @@ In general, **OK**, **Cancel**, and **Help** buttons should be arranged horizont
 
 ![Acceptable configurations for control buttons in Visual Studio dialogs](../../extensibility/ux-guidelines/media/0704-04_controlbuttonconfig.png "0704-04_ControlButtonConfig")<br />Acceptable configurations for control buttons in Visual Studio dialogs
 
-The dialog must include a default control button. To determine the best command to use as the default, choose from the following options (listed in order of precedence):
+The dialog must include a default control button. This is a button that is invoked by pressing the Enter key - see [Button IsDefault](/dotnet/api/system.windows.controls.button.isdefault?view=netframework-4.7.2&preserve-view=true)
+.To determine the best command to use as the default, choose from the following options (listed in order of precedence):
 
 - Choose the safest and most secure command as the default. This means choosing the command most likely to prevent data loss and avoid unintended system access.
 
@@ -390,13 +391,7 @@ The dialog must include a default control button. To determine the best command
 Avoid choosing a permanently destructive action for the default command. If such a command is present, choose a safer command as the default instead.
 
 #### Access keys
-Do not use access keys for **OK**, **Cancel**, or **Help** buttons. These buttons are mapped to shortcut keys by default:
-
-| Button name | Keyboard shortcut |
-| --- | --- |
-| OK | Enter |
-| Cancel | Esc |
-| Help | F1 |
+Do not use access keys for **OK** or **Cancel**. Enter and Escape shortcuts can be set with [Button IsDefault](/dotnet/api/system.windows.controls.button.isdefault?view=netframework-4.7.2&preserve-view=true) and [Button IsCancel](/dotnet/api/system.windows.controls.button.iscancel?view=netframework-4.7.2&preserve-view=true) respectively.
 
 #### Imagery
 Use images sparingly in dialogs. Don't use large icons in dialogs merely to use up space. Use images only if they are an important part of conveying the message to the user, like warning icons or status animations.

docs/msbuild/msbuild-command-line-reference.md

@@ -78,7 +78,7 @@ Square brackets `[]` indicate optional parts, and curly braces `{}`indicate user
 
 |Switch|Description|
 |------------|-----------------|
-|`-binaryLogger[:[LogFile=]{output.binlog}`<br/>`[;ProjectImports=None`,`Embed`,`ZipFile]]`<br/><br/>`-bl[:[LogFile=]{output.binlog}`<br/>`[;ProjectImports=None`,`Embed`,`ZipFile]]`|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.<br /><br />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` parameter controls this behavior:<br /><br /> -   **ProjectImports=None**. Don't collect the project imports.<br /> -   **ProjectImports=Embed**. Embed project imports in the log file (default).<br /> -   **ProjectImports=ZipFile**. Save project files to *{output}.projectimports.zip* where \<output> is the same name as the binary log file name.<br /><br />The default setting for ProjectImports is Embed.<br />**Note**: the logger doesn't collect non-MSBuild source files such as `.cs`, `.cpp`, and so on.<br />A *.binlog* file can be "played back" by passing it to *msbuild.exe* as an argument instead of a project/solution. Other loggers 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 <br /><br />**Examples**:<br /> -   `-bl`<br /> -    `-bl:output.binlog`<br /> -   `-bl:output.binlog;ProjectImports=None`<br /> -   `-bl:output.binlog;ProjectImports=ZipFile`<br /> -   `-bl:..\..\custom.binlog`<br /> -   `-binaryLogger`|
+|`-binaryLogger[:[LogFile=]{output.binlog}`<br/>`[;ProjectImports=None`,`Embed`,`ZipFile]]`<br/><br/>`-bl[:[LogFile=]{output.binlog}`<br/>`[;ProjectImports=None`,`Embed`,`ZipFile]]`|Serializes all build events to a compressed binary file. By default the file is in the current directory and named *msbuild.binlog*. The optional `LogFile` parameter accepts a string of the form `{filename}.binlog`, where `{filename}` contains valid file system characters, but also accepts a placeholder symbol `{}`. If `{}` is provided, MSBuild will fill that position with a 'unique stamp' of the form `yyyyMMdd-HHmmss--<current process id>--<6-character random string>`. 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.<br /><br />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` parameter controls this behavior:<br /><br /> -   **ProjectImports=None**. Don't collect the project imports.<br /> -   **ProjectImports=Embed**. Embed project imports in the log file (default).<br /> -   **ProjectImports=ZipFile**. Save project files to *{output}.projectimports.zip* where \<output> is the same name as the binary log file name.<br /><br />The default setting for ProjectImports is Embed.<br />**Note**: the logger doesn't collect non-MSBuild source files such as `.cs`, `.cpp`, and so on.<br />A *.binlog* file can be "played back" by passing it to *msbuild.exe* as an argument instead of a project/solution. Other loggers 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 [MSBuild Binary Log overview](https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md). <br /><br />**Examples**:<br /> -   `-bl`<br /> -    `-bl:output.binlog`<br /> -   `-bl:output.binlog;ProjectImports=None`<br /> -   `-bl:output.binlog;ProjectImports=ZipFile`<br /> -   `-bl:..\..\custom.binlog`<br /> - `-bl:publish-{}.binlog`<br /> -   `-binaryLogger`|
 |`-consoleLoggerParameters:{parameters}`<br/><br/>`-clp:{parameters}`|Pass the parameters that you specify to the console logger, which displays build information in the console window. You can specify the following parameters:<br /><br /> -   **PerformanceSummary**. Show the time that's spent in tasks, targets, and projects.<br />-   **Summary**. Show the error and warning summary at the end.<br />-   **NoSummary**. Don't show the error and warning summary at the end.<br />-   **ErrorsOnly**. Show only errors.<br />-   **WarningsOnly**. Show only warnings.<br />-   **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 `diagnostic`.<br />-   **ShowCommandLine**. Show `TaskCommandLineEvent` messages.<br />-   **ShowProjectFile**. Show the path to the project file in diagnostic messages. This setting is on by default. <br />-   **ShowTimestamp**. Show the timestamp as a prefix to any message.<br />-   **ShowEventId**. Show the event ID for each started event, finished event, and message.<br />-   **ForceNoAlign**. Don't align the text to the size of the console buffer.<br />-   **DisableConsoleColor**. Use the default console colors for all logging messages.<br />-   **DisableMPLogging**. Disable the multiprocessor logging style of output when running in non-multiprocessor mode.<br />-   **EnableMPLogging**. Enable the multiprocessor logging style even when running in non-multiprocessor mode. This logging style is on by default.<br />-   **ForceConsoleColor**. Use ANSI console colors even if console doesn't support it.<br />-   **Verbosity**. Override the `-verbosity` setting for this logger.<br /><br /> Use a semicolon to separate multiple parameters, as the following example shows:<br /><br /> `-consoleLoggerParameters:PerformanceSummary;NoSummary -verbosity:minimal`<br/><br/> The default console logger is at normal verbosity and includes a `Summary`.|
 |`-distributedFileLogger`<br/><br/>`-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.<br /><br /> If you name a log file by using the `-fileLoggerParameters` switch, the distributed logger uses that name as a template and append the node ID to that name when creating a log file for each node.|
 |`-distributedLogger:{central logger},{forwarding logger}, ...`<br/><br/>`-dl:{central logger},{forwarding logger, ...}`|Log events from MSBuild, attaching a different logger instance to each node. To specify multiple loggers, specify each logger separately.<br /><br /> You use the logger syntax to specify a logger, except you provide and additional class for the forwarding logger. For the logger syntax, see the `-logger` switch.<br /><br /> The following examples show how to use this switch:<br /><br /> `-dl:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral`<br /><br /> `-dl:MyLogger,C:\My.dll*ForwardingLogger,C:\Logger.dll`|

docs/msbuild/property-functions.md

@@ -596,6 +596,7 @@ The following example shows how these functions are used.
         <Value5>$([MSBuild]::IsTargetFrameworkCompatible('net5.0-windows', 'net5.0'))</Value5>
         <Value6>$([MSBuild]::IsTargetFrameworkCompatible('net5.0', 'net6.0'))</Value6>
         <Value7>$([MSBuild]::IsTargetFrameworkCompatible('net5.0', 'net8.0'))</Value7>
+        <Value8>$([MSBuild]::IsTargetFrameworkCompatible('net8.0', 'net6.0'))</Value8>
     </PropertyGroup>
 
     <Target Name="MyTarget">
@@ -606,6 +607,7 @@ The following example shows how these functions are used.
         <Message Text="Value5 = $(Value5)" />
         <Message Text="Value6 = $(Value6)" />
         <Message Text="Value7 = $(Value7)" />
+        <Message Text="Value8 = $(Value8)" />
     </Target>
 </Project>
 ```
@@ -618,6 +620,7 @@ Value4 = 7.0
 Value5 = True
 Value6 = False
 Value7 = False
+Value8 = True
 ```
 
 ::: moniker range=">=vs-2022"