Merged main into live

Author: mijacobs

docs/debugger/debugging-absolute-beginners.md

@@ -1,7 +1,7 @@
 ---
 title: "Debugging code for absolute beginners"
 description: "If you're debugging for the first time, learn a few principles to help you run your app in debugging mode with Visual Studio."
-ms.date: 10/19/2023
+ms.date: 12/5/2024
 ms.topic: tutorial
 helpviewer_keywords:
   - "debugger"
@@ -309,7 +309,7 @@ Maffei 1, 11,  ConsoleApp_FirstApp.GType
 
 1. With the app still running, insert a breakpoint.
 
-    Right-click next to the `Console.WriteLine` method to get the context menu and select **Breakpoint** > **Insert Breakpoint** from the fly-out menu.
+    In the `foreach` loop, right-click next to the `Console.WriteLine` method to get the context menu and select **Breakpoint** > **Insert Breakpoint** from the fly-out menu.
 
     #### [C#](#tab/csharp)
 
@@ -339,26 +339,36 @@ Maffei 1, 11,  ConsoleApp_FirstApp.GType
 
 1. Hover over the `GalaxyType` variable on the right, and then, to the left of the wrench icon, expand `theGalaxy.GalaxyType`. You see that `GalaxyType` contains a property `MyGType`, and the property value is set to `Spiral`.
 
-    :::image type="content" source="../debugger/media/beginners-inspect-variable.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code in yellow and a menu open below the Galaxy GalaxyType property.":::
+    :::image type="content" source="../debugger/media/beginners-inspect-variable.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code in yellow and a menu open below the Galaxy GalaxyType property." lightbox="../debugger/media/beginners-inspect-variable.png":::
 
     "Spiral" is actually the correct value you were expecting to print to the console! So it's a good start that you can access the value in this code while running the app. In this scenario, we're using the incorrect API. Let's see if you can fix this while running code in the debugger.
 
-1. In the same code, while still debugging, put your cursor at the end of `theGalaxy.GalaxyType` and change it to `theGalaxy.GalaxyType.MyGType`. Although you can make the change, the code editor shows you an error indicating it can't compile this code. (In Visual Basic, the error isn't shown and this section of code works.)
+1. In the same code, while still debugging, put your cursor at the end of `theGalaxy.GalaxyType` and change it to `theGalaxy.GalaxyType.MyGType`. Although you can make the edit, the code editor shows you an error (red squiggly line). (In Visual Basic, the error isn't shown and this section of code works.)
 
 1. Press **F11** (**Debug** > **Step Into** or the **Step Into** button in the Debug Toolbar) to execute the current line of code.
 
     **F11** advances the debugger (and executes code) one statement at a time. **F10** (**Step Over**) is a similar command, and both are useful when learning how to use the debugger.
 
+   ::: moniker range=">= vs-2022"
+
+   When you try to advance the debugger, the Hot Reload dialog box appears, indicating that edits can't be compiled.
+
+   :::image type="content" source="../debugger/media/vs-2022/beginners-edit.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code highlighted in red and a message box with the Edit option selected.":::
+   ::: moniker-end
+
+   ::: moniker range="<= vs-2019"
+
    The Edit and Continue dialog box appears, indicating that edits can't be compiled.
 
-    :::image type="content" source="../debugger/media/beginners-edit.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code highlighted in red and a message box with the Edit option selected.":::
+   :::image type="content" source="../debugger/media/beginners-edit.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code highlighted in red and a message box with the Edit option selected.":::
+   ::: moniker-end
 
    > [!NOTE]
    > For debugging the Visual Basic example code, skip the next few steps until you're instructed to click the **Restart** :::image type="content" source="../debugger/media/dbg-tour-restart.png" alt-text="Icon showing Restart app button in Debug toolbar."::: button.
 
-1. Select **Edit** in the **Edit and Continue** message box. You see an error message now in the **Error List** window. The error indicates that the `'object'` doesn't contain a definition for `MyGType`.
+1. Select **Edit** in the **Hot Reload** or **Edit and Continue** message box. You see an error message now in the **Error List** window. The error indicates that the `'object'` doesn't contain a definition for `MyGType`.
 
-    :::image type="content" source="../debugger/media/beginners-no-definition.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code highlighted in red and an Error List window with two errors listed.":::
+    :::image type="content" source="../debugger/media/beginners-no-definition.png" alt-text="Screenshot of the Visual Studio Debugger with a line of code highlighted in red and an Error List window with two errors listed." lightbox="../debugger/media/beginners-no-definition.png":::
 
     Even though we set each galaxy with an object of type `GType` (which has the `MyGType` property), the debugger doesn't recognize the `theGalaxy` object as an object of type `GType`. What's going on? You want to look through any code that sets the galaxy type. When you do this, you see that the `GType` class definitely has a property of `MyGType`, but something isn't right. The error message about `object` turns out to be the clue; to the language interpreter, the type appears to be an object of type `object` instead of an object of type `GType`.
 

docs/debugger/media/vs-2022/beginners-edit.png

@@ -1,7 +1,7 @@
 ---
 title: "Remote Debug a C++ Project"
 description: Debug a Visual Studio C++ application from a remote computer, install and run remote tools, configure your project to connect, and deploy and run your app.
-ms.date: "03/20/2023"
+ms.date: "12/04/2024"
 ms.topic: "conceptual"
 dev_langs:
   - "C++"
@@ -93,9 +93,9 @@ The remote debugger is supported on Windows 7 and newer and versions of Windows
     > [!TIP]
     > Alternatively, you can deploy the files as a separate step. In the **Solution Explorer,** right-click the project node and then choose **Deploy**.
 
-    If you have non-code files that are required by the application, you can specify them in a semicolon delimited list in **Additional Files to Deploy** on the **Remote Windows Debugger** page.
+    If you have non-code files that are required by the application, you can specify them in a semicolon delimited list in **Additional Files to Deploy** on the **Debugger** properties page with **Remote Windows Debugger** selected.
 
-    Alternatively, you can include the files in your project, and set the **Content** property to **Yes** in the **Properties** page for each file. These files are copied to the **Deployment Directory** specified on the **Remote Windows Debugger** page. You can also change the **Item Type** to **Copy File** and specify additional properties there if you need the files to be copied to a subfolder of the **Deployment Directory**.
+    Alternatively, you can include the files in your project, and set the **Content** property to **Yes** in the **Properties** page for each file. These files are copied to the **Deployment Directory** specified on the **Debugger** properties page with **Remote Windows Debugger** selected. You can also change the **Item Type** to **Copy File** and specify additional properties there if you need the files to be copied to a subfolder of the **Deployment Directory**.
 
 ## Set Up Debugging with Remote Symbols
 

docs/debugger/remote-debugging-cpp.md

@@ -1,21 +1,50 @@
 ---
-title: Run a unit test as a 64-bit process
-description: Run unit tests and capture code coverage information as a 64-bit process, and recompile code or tests compiled as 32-bit/x86 to run them as a 64-bit process.
-ms.date: 03/10/2020
+title: Configure process architecture for unit tests
+description: Configure process architecture for unit tests and run unit tests and capture code coverage information as a 64-bit process, and recompile code or tests compiled as 32-bit/x86 to run them as a 64-bit process.
+ms.date: 12/4/2024
 ms.topic: how-to
 helpviewer_keywords: 
-  - unit tests, creating
-  - unit tests, running
+  - unit tests, process architecture
+  - unit tests, 64-bit process
 ms.author: mikejo
 manager: mijacobs
 ms.subservice: test-tools
 author: mikejo5000
 ---
-# Run a unit test as a 64-bit process
+# Configure process architecture for a unit test
+
+::: moniker range=">=vs-2022"
+This article provides information on the process architecture used for running unit tests, how to set the process architecture, and how to run unit tests as a 64-bit process.
+::: moniker-end
+
+::: moniker range="<=vs-2019"
+This article provides information on how to set the process architecture for unit tests and how to run unit tests as a 64-bit process.
+::: moniker-end
+
+::: moniker range=">=vs-2022"
+## Configure process architecture for MSTest projects
+
+For MSTest projects using Visual Studio Testing Platform (VSTest) as the test runner, the default target platform (process architecture) matches the operating system's architecture. You can override this behavior for projects set to **Any CPU** as the target platform using either the Test Explorer **Settings**, as shown in the following illustration, or using the **Test** menu.
+
+:::image type="content" source="../test/media/vs-2022/menu-process-architecture-for-anycpu.png" alt-text="Screenshot showing menu for selecting the processor architecture for AnyCPU." lightbox="../test/media/vs-2022/menu-process-architecture-for-anycpu.png":::
+
+From the **Test** menu, select **Processor Architecture for AnyCPU Projects**.
+
+For projects using MSTest as the test runner instead of VSTest, the architecture is determined strictly by MSBuild and runtime rules. Executables are generated based on the preferred architecture specified in MSBuild/runtime settings. You can adjust this preference using MSBuild properties (for example, **PreferNativeArm64**), but the setting **Processor Architecture for AnyCPU Projects** cannot be used to change the architecture for these projects.
+
+> [!NOTE]
+> You can set the test runner when you create a unit test project using the MSTest project template, or by using MSBuild properties. For more information on the difference between MSTest and VSTest test runners, see [Microsoft.Testing.Platform and VSTest comparison](/dotnet/core/testing/unit-testing-platform-vs-vstest).
+
+### PreferNativeArm64 (MSTest)
+
+When using the `PreferNativeArm64` MSBuild property, the project prefers running natively on ARM64 architecture if it's available. This property is applicable to projects that generate executables and follow MSBuild runtime rules. This setting is ignored for Visual Studio Test Platform (VSTest) test runners and only applies to MSTest projects with MSTest configured as the test runner. 
+::: moniker-end
+
+## Run a unit test as a 64-bit process
 
 If you have a 64-bit machine, you can run unit tests and capture code coverage information as a 64-bit process.
 
-## To run a unit test as a 64-bit process
+To run a unit test as a 64-bit process:
 
 1. If your code or tests were compiled as 32-bit/x86, but you now want to run them as a 64-bit process, recompile them as **Any CPU**.
 
@@ -30,6 +59,11 @@ If you have a 64-bit machine, you can run unit tests and capture code coverage i
 
    Specify `<TargetPlatform>x64</TargetPlatform>` in a *.runsettings* file. An advantage of this method is that you can specify groups of settings in different files and quickly switch between different settings. You can also copy settings between solutions. For more information, see [Configure unit tests by using a .runsettings file](../test/configure-unit-tests-by-using-a-dot-runsettings-file.md).
 
+   ::: moniker range=">=vs-2022"
+   > [!NOTE]
+   > The **Processor Architecture for AnyCPU projects** setting is not supported in an MSTest project if you set MSTest as the test runner instead of VSTest.
+   ::: moniker-end
+
 ## Related content
 
 - [Run unit tests with Test Explorer](../test/run-unit-tests-with-test-explorer.md)

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

@@ -1,7 +1,7 @@
 ---
 title: Run unit tests with Test Explorer
 description: Run tests with Test Explorer in Visual Studio, enable automatic tests after build, view results, group and filter the test list, create playlists, and use shortcuts.
-ms.date: 11/18/2024
+ms.date: 12/3/2024
 ms.topic: how-to
 author: mikejo5000
 ms.author: mikejo
@@ -57,17 +57,8 @@ You can run all the tests in the solution, all the tests in a group, or a set of
 
 - If individual tests have no dependencies that prevent them from being run in any order, turn on parallel test execution in the settings menu of the toolbar. This can noticeably reduce the time taken to run all the tests.
 
-### Configure process architecture for AnyCPU (MSTest)
-
-For MSTest projects using Visual Studio Testing Platform (vstest) as the test runner, the default architecture matches the operating system's architecture. You can override this behavior for AnyCPU projects through the Test Explorer menu shown in the image below.
-
-:::image type="content" source="../test/media/vs-2022/menu-process-architecture-for-anycpu.png" alt-text="Screenshot showing menu for selecting the processor architecture for AnyCPU." lightbox="../test/media/vs-2022/menu-process-architecture-for-anycpu.png":::
-
-For projects using MSTest as the test runner instead of Visual Studio Test Platform (vstest), the architecture is determined strictly by MSBuild and runtime rules. Executables are generated based on the preferred architecture specified in MSBuild/runtime settings. You can adjust this preference using MSBuild properties (e.g., **PreferNativeArm64**), but the Test Explorer menu **Processor Architecture for AnyCPU Projects** cannot be used to change the architecture for these projects.
-
-#### PreferNativeArm64
-
-When using this MSBuild property, the project will prefer running natively on ARM64 architecture if available. This property is applicable to projects that generate executables and follow MSBuild/runtime rules. It is important to note that this setting is ignored for Visual Studio Test Platform (vstest) test projects and only applies to MSTest projects with MSTest configured as the test runner. 
+>![NOTE]
+> To configure the target platform (process architecture) for running unit tests, see [Configure process architecture for a unit test](../test/run-a-unit-test-as-a-64-bit-process.md).
 
 ### Run tests after every build
 

docs/test/run-unit-tests-with-test-explorer.md

@@ -1,7 +1,7 @@
 ---
 title: Create, run, and customize C# unit tests
 description: Learn how to create, run, and customize a series of unit tests using the Microsoft unit test framework for managed code and Visual Studio Test Explorer.
-ms.date: 11/18/2024
+ms.date: 12/3/2024
 ms.topic: conceptual
 helpviewer_keywords:
 - unit tests, walkthrough
@@ -121,7 +121,7 @@ You now have a project with methods you can test. In this article, the tests foc
    > [!TIP]
    > You can also right-click on the solution in **Solution Explorer** and choose **Add** > **New Project**.
 
-1. Type **test** in the search box, select **C#** as the language, and then select the C# **MSTest Unit Test Project** for .NET template, and then click **Next**.
+1. Type **test** in the search box, select **C#** as the language, and then select the C# **MSTest Test Project** for .NET template, and then click **Next**.
 
    > [!NOTE]
    > In Visual Studio 2019 version 16.9, the MSTest project template is **Unit Test Project**.
@@ -130,6 +130,10 @@ You now have a project with methods you can test. In this article, the tests foc
 
 1. Choose either the recommended target framework or .NET 8, and then choose **Create**.
 
+   ::: moniker range=">=vs-2022"
+   Starting in Visual Studio 2022 version 17.10, you can also select a test runner. For the test runner, you can choose either **VSTest** or **MSTest**. For more information on the difference between test runners, see [Microsoft.Testing.Platform and VSTest comparison](/dotnet/core/testing/unit-testing-platform-vs-vstest).
+   ::: moniker-end
+
    The **BankTests** project is added to the **Bank** solution.
 
 1. In the **BankTests** project, add a reference to the **Bank** project.