Merge pull request #5747 from MicrosoftDocs/master637333040053523091

For protected CLA branch, push strategy should use PR and merge to target branch method to work around git push error

Author: ghogen

docs/get-started/csharp/tutorial-console-part-2.md

@@ -18,7 +18,7 @@ ms.workload:
 ---
 # Tutorial: Extend a simple C# console app
 
-In this tutorial, you'll learn how to use Visual Studio to extend the console app you created in the first part. You'll learn some of the features in Visual Studio that help you be more productive as a developer, such as using advanced editor features, and debugging.
+In this tutorial, you'll learn how to use Visual Studio to extend the console app you created in the first part. You'll learn some of the features in Visual Studio that you'll need for daily development, such as managing multiple projects, and referencing third-party packages.
 
 If you just completed the [first part](tutorial-console.md) of this series, you already have the Calculator console app.  To skip part 1, you can start by opening the project from a GitHub repo. The C# Calculator app is in the [vs-tutorial-samples repo](https://github.com/MicrosoftDocs/vs-tutorial-samples), so you can just follow the steps in [Tutorial: Open a project from a repo](../tutorial-open-project-from-repo.md) to get started.
 

docs/get-started/csharp/tutorial-console.md

@@ -594,10 +594,10 @@ namespace Calculator
 
 ## Next steps
 
-Congratulations on completing this tutorial! To learn even more, continue with the following tutorials.
+Continue with the second part of this tutorial:
 
 > [!div class="nextstepaction"]
-> [Continue with more C# tutorials](/dotnet/csharp/tutorials/)
+> [Continue with Part 2](tutorial-console-part-2.md)
 
 ## See also
 

docs/profiling/profile-apps-from-command-line.md

@@ -36,9 +36,9 @@ Profiling using the Visual Studio Diagnostics CLI tools works by attaching the p
 
 1. Start Notepad, and then open Task Manager to get its process ID (PID). In Task Manager, find the PID in the **Details** tab.
 
-1. Open a command prompt and change to the directory with the collection agent executable, typically here.
+1. Open a command prompt and change to the directory with the collection agent executable, typically here (for Visual Studio Enterprise).
 
-   ```<Visual Studio installation folder>\2019\Preview\Team Tools\DiagnosticsHub\Collector\```
+   ```<Visual Studio installation folder>\2019\Enterprise\Team Tools\DiagnosticsHub\Collector\```
 
 1. Start *VSDiagnostics.exe* by typing the following command.
 
@@ -49,9 +49,15 @@ Profiling using the Visual Studio Diagnostics CLI tools works by attaching the p
    The arguments that must be included are:
 
    * \<*id*> Identifies the collection session. The ID must be a number between 1-255.
-   * \<*pid*>, PID of the process you wish to profile, in this case the PID you found in step 1
+   * \<*pid*>, PID of the process you wish to profile, in this case the PID you found in step 1.
    * \<*configFile*>, configuration file for the collection agent you wish to launch. For more information, see [Configuration files for agents](#config_file).
 
+   For example, you could use the following command for the CPUUsageBase agent by replacing the *pid* as described previously.
+
+   ```cmd
+   VSDiagnostics.exe start 1 /attach:<pid> /loadConfig:AgentConfigs\CPUUsageLow.json
+   ```
+
 1. Resize Notepad, or type something in it in order to make sure that some interesting profiling information is collected.
 
 1. Stop the collection session and send output to a file by typing the following command.
@@ -60,7 +66,9 @@ Profiling using the Visual Studio Diagnostics CLI tools works by attaching the p
    VSDiagnostics.exe stop <id> /output:<path to file>
    ```
 
-1. Go to the file output from the previous command, and open it in Visual Studio to examine the information collected.
+1. Locate the *.diagsession* file output from the previous command, and open it in Visual Studio (**File** > **Open**) to examine the information collected.
+
+   To analyze the results, see the documentation for the corresponding performance tool. For example, this might be the [CPU Usage](../profiling/cpu-usage.md), [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md), or the [Database](../profiling/analyze-database.md) tool.
 
 ## <a name="config_file"></a> Agent configuration files
 

docs/profiling/running-profiling-tools-with-or-without-the-debugger.md

@@ -83,88 +83,4 @@ You can save the reports, and open them from the **Recently Opened Sessions** li
 
 ## Collect profiling data from the command line
 
-To measure performance data from the command line, you can use VSDiagnostics.exe, which is included with either Visual Studio or the Remote Tools. This is useful for capturing performance traces on systems where Visual Studio isn't installed, or for scripting the collection of performance traces. When you use VSDiagnostics.exe, you begin a diagnostic session that captures and stores profiling data until the tool is stopped. At that point, that data is exported into a .diagsession file, and you can open this file in Visual Studio to analyze results.
-
-### Launch an application
-
-1. Open a command prompt, and change to the directory with VSDiagnostics.exe:
-
-   ```
-   <Visual Studio Install Folder>\Team Tools\DiagnosticsHub\Collector\
-   ```
-
-2. Start VSDiagnostics.exe with the following command:
-
-   ```
-   VSDiagnostics.exe start <id> /launch:<appToLaunch> /loadConfig:<configFile>
-   ```
-
-   You must include the following arguments:
-
-   - \<id\>: Identifies the collection session. The ID must be a number between 1-255.
-   - \<appToLaunch\>: The executable file to launch and profile.
-   - \<configFile\>: The configuration file for the collection agent you want to launch.
-
-3. To stop collection and view your results, follow the steps in the "Stop collection" section later in this article.
-
-### Attach to an existing application
-
-1. Open an application, such as Notepad, and then open **Task Manager** to get its process ID (PID). In Task Manager, find the PID in the **Details** tab.
-2. Open a command prompt, and change to the directory with the collection agent executable. Typically, it's here:
-
-   ```
-   <Visual Studio installation folder>\2019\Preview\Team Tools\DiagnosticsHub\Collector\
-   ```
-
-3. Start the VSDiagnostics.exe file by typing the following command.
-
-   ```
-   VSDiagnostics.exe start <id> /attach:<pid> /loadConfig:<configFile>
-   ```
-
-   You must include the following arguments:
-
-   - \<id\>: Identifies the collection session. The ID must be a number between 1-255.
-   - \<pid\>: The PID of the process you want to profile, which in this case is the PID you found in step 1.
-   - \<configFile\>: The configuration file for the collection agent you want to launch. For more information, see [Configuration files for agents](../profiling/profile-apps-from-command-line.md).
-
-4. To stop collection and view your results, follow the steps in the next section.
-
-### Stop collection
-
-1. Stop the collection session, and send output to a file, by typing the following command.
-
-   ```
-   VSDiagnostics.exe stop <id> /output:<path to file>
-   ```
-
-2. Go to the file output from the previous command, and open it in Visual Studio to examine the information collected.
-
-## Agent configuration files
-
-Collection agents are interchangeable components that collect different types of data, depending on what you are trying to measure.
-For convenience, you can store that information in an agent configuration file. The configuration file is a .json file that contains, at minimum, the name of the .dll file and its COM CLSID. Here are the example configuration files that you can find in the following folder:
-
-```
-<Visual Studio installation folder>\Team Tools\DiagnosticsHub\Collector\AgentConfigs\
-```
-
-Please see the following links to download and view agent configuration files:
-
-- https://aka.ms/vs/diaghub/agentconfig/cpubase
-- https://aka.ms/vs/diaghub/agentconfig/cpuhigh
-- https://aka.ms/vs/diaghub/agentconfig/cpulow
-- https://aka.ms/vs/diaghub/agentconfig/database
-- https://aka.ms/vs/diaghub/agentconfig/dotnetasyncbase
-- https://aka.ms/vs/diaghub/agentconfig/dotnetallocbase
-- https://aka.ms/vs/diaghub/agentconfig/dotnetalloclow
-
-CpuUsage configurations (Base/High/Low) correspond to data collected for the [CPU Usage](../profiling/cpu-usage.md) profiling tool.
-DotNetObjectAlloc configurations (Base/Low) correspond to data collected for the [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md).
-
-Base/Low/High configurations refer to the sampling rate. For example, Low is 100 samples/second and High is 4000 samples/second.
-For the VSDiagnostics.exe tool to work with a collection agent, it requires both a DLL and a COM CLSID for the appropriate agent. The agent might also have additional configuration options. If you use an agent without a configuration file, use the format in the following command:
-
-```
-VSDiagnostics.exe start <id> /attach:<pid> /loadAgent:<agentCLSID>;<agentName>[;<config>]
-```
+To measure performance data from the command line, you can use VSDiagnostics.exe, which is included with either Visual Studio or the Remote Tools. This is useful for capturing performance traces on systems where Visual Studio isn't installed, or for scripting the collection of performance traces. For detailed instructions, see [Measure application performance from the command line](../profiling/profile-apps-from-command-line.md).

docs/test/run-a-unit-test-as-a-64-bit-process.md

@@ -24,7 +24,7 @@ If you have a 64-bit machine, you can run unit tests and capture code coverage i
    ::: moniker-end
 
     > [!TIP]
-    > For maximum flexibility, compile your test projects with the **Any CPU** configuration. Then you can run on both 32-bit and 64-bit agents. There's no advantage to compiling test projects with the **64-bit** configuration.
+    > For maximum flexibility, compile your test projects with the **Any CPU** configuration. Then you can run on both 32-bit and 64-bit agents. There's no advantage to compiling test projects with the **64-bit** configuration, unless you are calling code that is only supported on 64-bit.
 
 2. Set the unit tests to run as a 64-bit process.