Merging changes synced from https://github.com/MicrosoftDocs/visualstudio-docs-pr (branch live)

Author: opbld17

docs/azure/vs-azure-tools-azure-project-create.md

@@ -18,7 +18,6 @@ Visual Studio provides a project template that lets you create an [Azure cloud s
 ## Steps to create an Azure cloud service project in Visual Studio
 This section walks you through creating an Azure cloud service project in Visual Studio with one or more web roles.
 
-::: moniker range=">=vs-2019"
 1. From the start window, choose **Create a new project**.
 
 1. In the search box, type in *Cloud*, and then choose **Azure Cloud Service**.
@@ -28,8 +27,6 @@ This section walks you through creating an Azure cloud service project in Visual
 1. Give the project a name and choose **Create**.
 
    ![Give the project a name](./media/vs-azure-tools-azure-project-create/vs-2019/new-project-cloud-service-2.png)
-::: moniker-end
-
 1. In the **New Microsoft Azure Cloud Service** dialog, select the roles that you want to add, and choose the right arrow button to add them to your solution.
 
     ![Select new Azure cloud service roles](./media/vs-azure-tools-azure-project-create/new-cloud-service.png)

docs/code-quality/code-metrics-values.md

@@ -41,12 +41,10 @@ The following list shows the code metrics results that Visual Studio calculates:
 
 - **Class Coupling** - Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. For more information, see [Class coupling](code-metrics-class-coupling.md).
 
-::: moniker range=">=vs-2019"
 
 - **Lines of Source code** - Indicates the exact number of source code lines that are present in your source file, including blank lines. This metric is available starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metrics (2.9.5).
 
 - **Lines of Executable code** - Indicates the approximate number of executable code lines or operations. This is a count of number of operations in executable code. This metric is available starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metrics (2.9.5). The value is typically a close match to the previous metric, **Lines of Code**, which is the MSIL-instruction-based metric used in legacy mode.
-::: moniker-end
 
 
 ## Anonymous methods

docs/code-quality/how-to-configure-code-analysis-for-a-managed-code-project.md

@@ -42,23 +42,17 @@ In Visual Studio, you can choose from a list of code analysis [rule sets](../cod
 2. In the **Configuration** and **Platform** lists, choose the build configuration and target platform.
 
 
-::: moniker range=">=vs-2019"
-
 3. To run code analysis every time the project is built using the selected configuration, select **Run on build** in the **Binary analyzers** section. You can also run legacy code analysis manually, see [How to: Run Legacy Code Analysis Manually for Managed Code](how-to-run-legacy-code-analysis-manually-for-managed-code.md) for more details.
 
-::: moniker-end
 
 4. To view warnings from generated code, clear the **Suppress results from generated code** check box.
 
     > [!NOTE]
     > This option does not suppress code analysis errors and warnings from generated code when the errors and warnings appear in forms and templates. You can both view and maintain the source code for a form or a template, and it won't be overwritten.
 
 
-::: moniker range=">=vs-2019"
-
 5. In the **Active rules** list, do one of the following:
 
-::: moniker-end
 
    - Select the rule set that you want to use.
 

docs/code-quality/how-to-create-a-custom-rule-set.md

@@ -30,11 +30,8 @@ To create a custom rule set, you can open a built-in rule set in the **rule set
 2. On the **Properties** pages, select the **Code Analysis** tab.
 
 
-::: moniker range=">=vs-2019"
-
 3. In the **Active rules** drop-down list, do one of the following:
 
-::: moniker-end
 
    - Choose the rule set that you want to customize.
 
@@ -69,11 +66,8 @@ You can create a new rule set file from the **New File** dialog:
 2. On the **Properties** pages, select the **Code Analysis** tab.
 
 
-::: moniker range=">=vs-2019"
-
 3. Select **\<Choose multiple rule sets>** from **Active rules**.
 
-::: moniker-end
 
 4. In the **Add or Remove Rule Sets** dialog box, choose the rule sets you want to include in your new rule set.
 

docs/code-quality/how-to-enable-and-disable-automatic-code-analysis-for-managed-code.md

@@ -27,8 +27,6 @@ To enable or disable legacy code analysis:
 3. Specify the build type in **Configuration** and the target platform in **Platform**. (Non-.NET Core/.NET Standard projects only.)
 
 
-::: moniker range=">=vs-2019"
-
 4. To enable or disable automatic code analysis, select or clear the **Run on build** check box in the **Binary analyzers** section.
 
    ![Run binary code analysis on build option in Visual Studio](media/run-on-build-binary-analyzers.png)
@@ -37,7 +35,6 @@ To enable or disable legacy code analysis:
 
    `<RunCodeAnalysis>false</RunCodeAnalysis>`
 
-::: moniker-end
 
 > [!NOTE]
 > Disabling binary code analysis on build does not affect [.NET Compiler Platform-based code analyzers](roslyn-analyzers-overview.md), which always execute at build if you installed them as a NuGet package. For information about disabling analysis from these analyzers, see [How to disable source code analysis](disable-code-analysis.md).

docs/code-quality/how-to-generate-code-metrics-data.md

@@ -146,7 +146,6 @@ Build succeeded.
 
 The generated XML output takes the following format:
 
-::: moniker range=">=vs-2019"
 
 ```xml
 <?xml version="1.0" encoding="utf-8"?>
@@ -203,7 +202,6 @@ The generated XML output takes the following format:
 </CodeMetricsReport>
 ```
 
-::: moniker-end
 
 
 ### Metrics.exe
@@ -246,19 +244,15 @@ For more information, see [Enable generating code metrics in legacy mode](https:
 
 ### Previous versions
 
-::: moniker range=">=vs-2019"
 Visual Studio 2015 included a command-line code metrics tool that was also called *Metrics.exe*. This previous version of the tool did a binary analysis, that is, an assembly-based analysis. The newer version of the *Metrics.exe* tool analyzes source code instead. Because the newer *Metrics.exe* tool is source code-based, command-line code metrics results may be different to those generated by the Visual Studio IDE and by previous versions of *Metrics.exe*. Starting in Visual Studio 2019, the Visual Studio IDE analyzes source code like the command-line tool and the results should be the same.
 
-::: moniker-end
 
 
 The new command-line code metrics tool computes metrics even in the presence of source code errors, as long as the solution and project can be loaded.
 
 #### Metric value differences
 
-::: moniker range=">=vs-2019"
 Starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metics (2.9.5), `SourceLines` and `ExecutableLines` replace the previous `LinesOfCode` metric. For descriptions of the new metrics, see [Code metrics values](../code-quality/code-metrics-values.md). The `LinesOfCode` metric is available in legacy mode.
-::: moniker-end
 
 
 Other metrics such as `CyclomaticComplexity` and `MaintainabilityIndex` use the same formulas as previous versions of *Metrics.exe*, but the new tool counts the number of `IOperations` (logical source instructions) instead of intermediate language (IL) instructions. The numbers will be slightly different to those generated by the Visual Studio IDE and by previous versions of *Metrics.exe*.

docs/code-quality/how-to-synchronize-code-project-rule-sets-with-team-project-check-in-policy.md

@@ -35,11 +35,8 @@ You synchronize the code analysis settings for code projects to the check-in pol
 2. Click **Code Analysis**.
 
 
-::: moniker range=">=vs-2019"
-
 3. In the **Active rules** list, select the check-in policy rule set.
 
-::: moniker-end
 
 ## To specify a custom check-in policy rule set
 
@@ -50,11 +47,8 @@ You synchronize the code analysis settings for code projects to the check-in pol
 3. Click **Code Analysis**.
 
 
-::: moniker range=">=vs-2019"
-
 4. In the **Active rules** list, click **\<Browse>**.
 
-::: moniker-end
 
 5. In the **Open** dialog box, specify the check-in policy rule set file.
 

docs/code-quality/implementing-custom-code-analysis-check-in-policies-for-managed-code.md

@@ -110,11 +110,8 @@ You specify a project check-in policy rule set as the code analysis rule set of
 4. If necessary, click the appropriate options in the **Configuration** and **Platform** lists.
 
 
-::: moniker range=">=vs-2019"
-
 5. To run code analysis every time that the code project is built using the specified configuration, select **Run on build** in the **Binary analyzers** section.
 
-::: moniker-end
 
 6. In the **Run this rule set** list, click **\<Browse>**.
 

docs/code-quality/in-source-suppression-overview.md

@@ -24,13 +24,11 @@ ms.workload:
 
 It is often useful to indicate that a warning is not applicable. Suppressing code analysis violations indicates team members the code was reviewed, and the warning can be suppressed. The following sections describe the different ways to suppress code analysis violations using the Visual Studio IDE.
 
-::: moniker range=">=vs-2019"
 
 ## Suppress violations using the EditorConfig file
 
 In an **EditorConfig file**, set the severity to `none`, for example, `dotnet_diagnostic.CA1822.severity = none`. To add an EditorConfig file, see [Add an EditorConfig file to a project](../ide/create-portable-custom-editor-options.md#add-and-remove-editorconfig-files).
 
-::: moniker-end
 
 ## Suppress violations in source code
 
@@ -42,13 +40,11 @@ You can suppress violations in code using a preprocessor directive, the [#pragma
 
   If you choose **in Source**, you see a preview of the preprocessor directive that will be added to your code.
 
-  ::: moniker range=">=vs-2019"
   :::image type="content" source="media/vs-2019/suppress-diagnostic-from-editor.png" alt-text="Suppress diagnostic from quick actions menu":::
 
   If you choose **in Source (attribute)**, you see a preview of the [SuppressMessage attribute](#in-source-suppression-and-the-suppressmessage-attribute) that will be added to your code.
 
   :::image type="content" source="media/vs-2019/suppress-diagnostic-from-editor-attribute.png" alt-text="Suppress diagnostic from quick actions menu using attribute":::
-  ::: moniker-end
 
 - From the **Error List**
 
@@ -75,11 +71,9 @@ The [global suppression file](#global-level-suppressions) uses the [SuppressMess
 
 - From the **code editor**, place the cursor in the line of code with the violation and press **Quick actions and refactorings** (or press **Ctrl**+**Period (.)**) to open the **Quick Actions** menu. Select **Suppress CAXXXX**, and then choose **in Suppression File**. You see a preview of the [global suppression file](#global-level-suppressions) that will be created or modified.
 
-::: moniker range=">=vs-2019"
 
 - From the **Analyze** menu, select **Analyze** > **Build and Suppress Active Issues** on the menu bar to suppress all current violations. Suppressing all current violations is sometimes referred to as "baselining".
 
-::: moniker-end
 
 
 ## Suppress violations using project settings
@@ -102,12 +96,9 @@ In C++/CLI, use the macros CA\_SUPPRESS\_MESSAGE or CA\_GLOBAL\_SUPPRESS_MESSAGE
 > You should not use in-source suppressions on release builds, to prevent shipping the in-source suppression metadata accidentally.
 
 
-::: moniker range=">=vs-2019"
-
 > [!NOTE]
 > If you migrate a project to Visual Studio 2019, you might suddenly be faced with a large number of code analysis warnings. If you aren't ready to fix the warnings, you can suppress all of them by selecting **Analyze** > **Build and Suppress Active Issues**.
 
-::: moniker-end
 
 ### SuppressMessage attribute
 

docs/code-quality/install-roslyn-analyzers.md

@@ -37,16 +37,13 @@ Visual Studio includes a core set of .NET Compiler Platform (*Roslyn*) analyzers
 ## To install VSIX analyzers
 
 
-::: moniker range=">=vs-2019"
-
 1. In Visual Studio, select **Extensions** > **Manage Extensions**.
 
    The **Manage Extensions** dialog box opens.
 
    > [!NOTE]
    > Alternatively, you can find and download the analyzer extension directly from [Visual Studio Marketplace](https://marketplace.visualstudio.com).
 
-::: moniker-end
 
 2. Expand **Online** in the left pane, and then select **Visual Studio Marketplace**.
 
@@ -69,11 +66,8 @@ Visual Studio includes a core set of .NET Compiler Platform (*Roslyn*) analyzers
 8. Open Visual Studio again.
 
 
-::: moniker range=">=vs-2019"
-
 If you want to check whether the extension is installed, select **Extensions** > **Manage Extensions**. In the **Manage Extensions** dialog box, select the **Installed** category on the left, and then search for the extension by name.
 
-::: moniker-end
 
 ## Next steps
 

docs/code-quality/static-code-analysis-for-managed-code-overview.md

@@ -56,12 +56,9 @@ Public class MyClass
 For more information, see [Suppress warnings](../code-quality/in-source-suppression-overview.md).
 
 
-::: moniker range=">=vs-2019"
-
 > [!NOTE]
 > If you migrate a project to Visual Studio 2019, you might suddenly be faced with a large number of code analysis warnings. If you aren't ready to fix the warnings, you can suppress all of them by choosing **Analyze** > **Build and Suppress Active Issues**.
 
-::: moniker-end
 
 ## Run code analysis as part of check-in policy
 

docs/code-quality/walkthrough-analyzing-managed-code-for-code-defects.md

@@ -59,13 +59,10 @@ This article steps you through the process of using legacy analysis to analyze y
 3. Choose the **Code Analysis** tab.
 
 
-::: moniker range=">=vs-2019"
-
 4. Make sure that **Run on build** is selected in the **Binary analyzers** section.
 
 5. From the **Active rules** drop-down list, select **Microsoft All Rules**.
 
-::: moniker-end
 
 6. On the **File** menu, click **Save Selected Items**, and then close the properties pages.
 

docs/containers/container-launch-settings.md

@@ -13,7 +13,6 @@ ms.topic: reference
 
 In the *Properties* folder in an ASP.NET Core project, you can find the launchSettings.json file, which contains settings that control how your web app is started on your development machine. For detailed information on how this file is used in ASP.NET development, see [Use multiple environments in ASP.NET Core](/aspnet/core/fundamentals/environments?view=aspnetcore-2.2&preserve-view=true). In *launchSettings.json*, the settings in the **Docker** section are related to how Visual Studio handles containerized apps.
 
-::: moniker range=">=vs-2019"
 
 ```json
     "Docker": {
@@ -31,7 +30,6 @@ In the *Properties* folder in an ASP.NET Core project, you can find the launchSe
     }
 ```
 
-::: moniker-end
 
 The commandName setting identifies that this section applies to Container Tools. The following table shows the properties that can be set in this section:
 

docs/containers/container-tools-configure.md

@@ -18,21 +18,17 @@ Using Visual Studio settings, you can control some aspects of how Visual Studio
 From the main menu, choose **Tools > Options**, and expand **Container Tools > Settings**. The container tools settings appear.
 
 
-::: moniker range=">=vs-2019"
-
 Container Tools **General** settings:
 
 ![Visual Studio Container Tools options, showing: Install Docker Desktop if needed, and Trust ASP.NET Core SSL certificate.](./media/configure-container-tools/tools-options-1.png)
 
 Container Tools **Single Project** and **Docker Compose** settings:
 
 ![Visual Studio Container Tools options, showing: Kill containers on project close, Pull required Docker images on project open, and Run containers on project open.](./media/configure-container-tools/tools-options-2.png)
-::: moniker-end
 
-The following table might help you decide how to set these options.
 
+The following table might help you decide how to set these options.
 
-::: moniker range=">=vs-2019"
 
 The following table describes **General** settings:
 
@@ -65,7 +61,6 @@ The following table describes the **Containers** window settings:
 | Confirm before removing an image | Always | Controls whether you are prompted when removing an image. |
 | Confirm before running large number of images | Always | Controls whether you are prompted before starting containers from more than 10 images at a time. |
 
-::: moniker-end
 > [!WARNING]
 > If the localhost SSL certificate is not trusted, and you check the box to suppress prompting, then HTTPS web requests might fail at run time in your app or service. In that case, uncheck the **Do not prompt** checkbox, run your project, and indicate trust at the prompt.