Merged main into live

Author: mijacobs

docs/debugger/attach-to-process-running-in-docker-container.md

@@ -1,7 +1,7 @@
 ---
 title: Attach to a process running on a Docker container
 description: Explore how to debug an application running a Windows Docker container or a Linux .NET Core Docker container by using Visual Studio.
-ms.date: "05/01/2024"
+ms.date: "11/19/2024"
 ms.topic: "conceptual"
 helpviewer_keywords:
   - "debugging, linux Docker container"
@@ -34,6 +34,9 @@ You can attach the Visual Studio debugger to a process running in a Linux .NET C
 > [!IMPORTANT]
 > To use this feature, you must have local access to the source code.
 
+> [!NOTE]
+> You can use these instructions to attach to Linux Docker running in WSL over SSH, but your WSL instance must first run an SSH server. For example, you could install Open SSH Server (for example: `sudo apt-get install openssh-server`), configure the server by editing the configuration file (for example: /etc/ssh/sshd_config), and then start the server (for example: `sudo service ssh start`).
+
 To attach to a running process in a Linux Docker container:
 
 1. In Visual Studio, select **Debug > Attach to Process (CTRL+ALT+P)** to open the **Attach to Process** dialog box.

docs/debugger/debug-dotnet-core-in-wsl-2.md

@@ -19,7 +19,7 @@ You can easily run and debug your .NET Core and .NET 5+ apps in Linux without le
 
 For a Windows .NET user targeting Linux, WSL lives in a sweet spot between production realism and productivity. In Visual Studio, you can already debug in a remote Linux environment using the [remote debugger](../debugger/remote-debugging-dotnet-core-linux-with-ssh.md), or with containers using the [Container Tools](../containers/overview.md). When production realism is your main concern, you should use one of those options. When an easy and fast inner-loop is more important, WSL is a great option.
 
-You don't have to choose just one method! You can have a launch profile for Docker and WSL in the same project and pick whichever is appropriate for a particular run. And once your app is deployed, you can always use the remote debugger to attach to it if there's an issue.
+You don't have to choose just one method! You can have a launch profile for Docker and WSL in the same project and pick whichever is appropriate for a particular run. And once your app is deployed, you can always use the remote debugger to attach to it if there's an issue. To debug a Linux Docker container running in WSL, see [Attach to a process running on a Docker container](../debugger/attach-to-process-running-in-docker-container.md).
 
 > [!NOTE]
 > Starting in Visual Studio 2019 version 16.11 Preview 3, the WSL 2 debug target was renamed to WSL.

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

@@ -79,7 +79,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`|
-|`-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`.|
+|`-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`|
 |`-fileLogger[{number}]`<br/><br/>`-fl[{number}]`|Log the build output to a single file in the current directory. If you don't specify `number`, the output file is named *msbuild.log*. If you specify `number`, the output file is named *msbuild\<n>.log*, where \<n> is `number`. `Number` can be a digit from 1 to 9.<br /><br /> You can use the `-fileLoggerParameters` switch to specify the location of the file and other parameters for the fileLogger.|