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

Author: opbld17

README.md

@@ -1,6 +1,6 @@
 # Visual Studio documentation
 
-Welcome! This repo contains source files for the Visual Studio technical documentation. The topics are published at [Visual Studio product family documentation](https://docs.microsoft.com/visualstudio).
+Welcome! This repo contains source files for the Visual Studio technical documentation. The topics are published at [Visual Studio product family documentation](https://learn.microsoft.com/visualstudio).
 
 This repo was moved on June 23, 2017 from https://github.com/Microsoft/vsdocs.
 

docs/containers/includes/vs-2017/container-tools.md

@@ -13,7 +13,7 @@ With Visual Studio, you can easily build, debug, and run containerized ASP.NET C
 ## Prerequisites
 
 * [Docker Desktop](https://hub.docker.com/editions/community/docker-ce-desktop-windows)
-* [Visual Studio 2017](https://visualstudio.microsoft.com/vs/older-downloads/?utm_medium=microsoft&utm_source=docs.microsoft.com&utm_campaign=vs+2017+download) with the **Web Development**, **Azure Tools** workload, and/or **.NET Core cross-platform development** workload installed
+* [Visual Studio 2017](https://visualstudio.microsoft.com/vs/older-downloads/?utm_medium=microsoft&utm_source=learn.microsoft.com&utm_campaign=vs+2017+download) with the **Web Development**, **Azure Tools** workload, and/or **.NET Core cross-platform development** workload installed
 * To publish to Azure Container Registry, an Azure subscription. [Sign up for a free trial](https://azure.microsoft.com/free/dotnet/).
 
 ## Installation and setup

docs/debugger/attach-to-running-processes-with-the-visual-studio-debugger.md

@@ -169,7 +169,7 @@ If neither of those workarounds is possible, a third option is to attach to the
 ::: moniker range=">= vs-2022"
 ## Attach to a .NET Core process running on Azure App Service (Windows)
 
-If you're publishing to Azure App Service (Windows), see [Remote debug ASP.NET Core on Azure](/learn/modules/dotnet-debug-visual-studio-azure-web-apps/) or [Debugging Azure App Services](/azure/vs-azure-tools-debug-cloud-services-virtual-machines#debugging-azure-app-services) for instructions.
+If you're publishing to Azure App Service (Windows), see [Remote debug ASP.NET Core on Azure](/training/modules/dotnet-debug-visual-studio-azure-web-apps/) or [Debugging Azure App Services](/azure/vs-azure-tools-debug-cloud-services-virtual-machines#debugging-azure-app-services) for instructions.
 ::: moniker-end
 
 ::: moniker range="vs-2019"

docs/debugger/remote-debugging-aspnet-on-a-remote-iis-7-5-computer.md

@@ -23,7 +23,7 @@ To debug an ASP.NET application that has been deployed to IIS, install and run t
 This guide explains how to set up and configure a Visual Studio ASP.NET MVC 4.8 application, deploy it to IIS, and attach the remote debugger from Visual Studio.
 
 > [!NOTE]
-> To remote debug ASP.NET Core instead, see [Remote Debug ASP.NET Core on an IIS Computer](../debugger/remote-debugging-aspnet-on-a-remote-iis-computer.md). For Azure App Service, see [Remote debug ASP.NET Core on Azure](/learn/modules/dotnet-debug-visual-studio-azure-web-apps/) or, for Visual Studio Enterprise, use the [Snapshot Debugger](../debugger/debug-live-azure-applications.md) (.NET 4.6.1 required).
+> To remote debug ASP.NET Core instead, see [Remote Debug ASP.NET Core on an IIS Computer](../debugger/remote-debugging-aspnet-on-a-remote-iis-computer.md). For Azure App Service, see [Remote debug ASP.NET Core on Azure](/training/modules/dotnet-debug-visual-studio-azure-web-apps/) or, for Visual Studio Enterprise, use the [Snapshot Debugger](../debugger/debug-live-azure-applications.md) (.NET 4.6.1 required).
 
 ## Prerequisites
 
@@ -278,4 +278,4 @@ In addition, these ports should already be opened by the ASP.NET installation:
 
     If you want more details on configuring Windows Firewall, see [Configure the Windows Firewall for Remote Debugging](../debugger/configure-the-windows-firewall-for-remote-debugging.md).
 
-3. Create additional rules for the other required ports.
+3. Create additional rules for the other required ports.

docs/debugger/remote-debugging-aspnet-on-a-remote-iis-computer.md

@@ -21,7 +21,7 @@ To debug an ASP.NET Core application that has been deployed to IIS, install and
 
 ![Remote debugger components](../debugger/media/remote-debugger-aspnet.png "Remote_debugger_components")
 
-This guide explains how to set up and configure a Visual Studio ASP.NET Core, deploy it to IIS, and attach the remote debugger from Visual Studio. To remote debug ASP.NET 4.8, see [Remote Debug ASP.NET on an IIS Computer](../debugger/remote-debugging-aspnet-on-a-remote-iis-7-5-computer.md). You can also deploy and debug on IIS using Azure. For Azure App Service, see [Remote debug ASP.NET Core on Azure](/learn/modules/dotnet-debug-visual-studio-azure-web-apps/) or, for Visual Studio Enterprise, use the [Snapshot Debugger](../debugger/debug-live-azure-applications.md) (.NET 4.6.1 required).
+This guide explains how to set up and configure a Visual Studio ASP.NET Core, deploy it to IIS, and attach the remote debugger from Visual Studio. To remote debug ASP.NET 4.8, see [Remote Debug ASP.NET on an IIS Computer](../debugger/remote-debugging-aspnet-on-a-remote-iis-7-5-computer.md). You can also deploy and debug on IIS using Azure. For Azure App Service, see [Remote debug ASP.NET Core on Azure](/training/modules/dotnet-debug-visual-studio-azure-web-apps/) or, for Visual Studio Enterprise, use the [Snapshot Debugger](../debugger/debug-live-azure-applications.md) (.NET 4.6.1 required).
 
 ## Prerequisites
 

docs/debugger/remote-debugging-azure.md

@@ -21,7 +21,7 @@ This guide explains how to set up and configure a Visual Studio ASP.NET Core app
 
 For IIS scenarios, Linux is not supported.
 
-To debug IIS on an Azure VM, follow steps in this topic. Using this method, you can use a customized configuration of IIS, but the setup and deployment steps are more complicated. If you don't need to customize IIS for your scenario, you might choose simpler methods to host and debug the app in [Azure App Service](/learn/modules/dotnet-debug-visual-studio-azure-web-apps/) instead.
+To debug IIS on an Azure VM, follow steps in this topic. Using this method, you can use a customized configuration of IIS, but the setup and deployment steps are more complicated. If you don't need to customize IIS for your scenario, you might choose simpler methods to host and debug the app in [Azure App Service](/training/modules/dotnet-debug-visual-studio-azure-web-apps/) instead.
 
 For an Azure VM, you must deploy your app from Visual Studio to Azure and you also need to manually install the IIS role and the remote debugger, as shown in the following illustration.
 

docs/debugger/remote-debugging.md

@@ -32,7 +32,7 @@ For in-depth instructions on remote debugging, see these topics.
 
 |Scenario|Link|
 |-|-|-|
-|Azure App Service|[Remote debug ASP.NET Core on Azure](/learn/modules/dotnet-debug-visual-studio-azure-web-apps/) or, for Visual Studio Enterprise, the [Snapshot Debugger](../debugger/debug-live-azure-applications.md)|
+|Azure App Service|[Remote debug ASP.NET Core on Azure](/training/modules/dotnet-debug-visual-studio-azure-web-apps/) or, for Visual Studio Enterprise, the [Snapshot Debugger](../debugger/debug-live-azure-applications.md)|
 |Azure VM|[Remote debug ASP.NET on an Azure VM](../debugger/remote-debugging-azure.md)|
 |Azure Service Fabric|[Debug an Azure Service Fabric application](/azure/service-fabric/service-fabric-debugging-your-application#debug-a-remote-service-fabric-application)|
 |ASP.NET|[Remote debug ASP.NET Core](../debugger/remote-debugging-aspnet-on-a-remote-iis-computer.md) or [Remote Debug ASP.NET](../debugger/remote-debugging-aspnet-on-a-remote-iis-7-5-computer.md)|
@@ -136,4 +136,4 @@ For debugging in ASP.NET and other server environments, you must either run the
 - [Configure the Windows Firewall for Remote Debugging](../debugger/configure-the-windows-firewall-for-remote-debugging.md)
 - [Remote Debugger Port Assignments](../debugger/remote-debugger-port-assignments.md)
 - [Remote Debugging ASP.NET Core on a Remote IIS Computer](../debugger/remote-debugging-aspnet-on-a-remote-iis-computer.md)
-- [Remote Debugging Errors and Troubleshooting](../debugger/remote-debugging-errors-and-troubleshooting.md)
+- [Remote Debugging Errors and Troubleshooting](../debugger/remote-debugging-errors-and-troubleshooting.md)

docs/debugger/unable-to-connect-to-the-microsoft-visual-studio-remote-debugging-monitor.md

@@ -69,7 +69,7 @@ If these values are correct and the message mentions **Windows Authentication**
 
 ## <a name="connection_terminated"></a> Connection with the remote endpoint was terminated
 
-If you are debugging an Azure App Service app, try following instructions in [Remote debug ASP.NET Core on Azure](/learn/modules/dotnet-debug-visual-studio-azure-web-apps/) to connect to Azure App Service.
+If you are debugging an Azure App Service app, try following instructions in [Remote debug ASP.NET Core on Azure](/training/modules/dotnet-debug-visual-studio-azure-web-apps/) to connect to Azure App Service.
 
 If you are using **Attach to Process** to debug:
 

docs/deployment/building-clickonce-applications-from-the-command-line.md

@@ -91,7 +91,7 @@ Once you have the publish profile created, you can provide the pubxml file as a
 
 ## Publish properties
 
- When you publish the application in the above procedures, the following properties are inserted into your project file by the Publish Wizard or in the publish profile file for .NET Core 3.1, or later projects. These properties directly influence how the [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application is produced.
+ When you publish the application in the above procedures, the following properties are inserted into your project file by the Publish Wizard or in the publish profile file for .NET projects (.NET Core 3.1, .NET 5, and later). These properties directly influence how the [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application is produced.
 
  In *CmdLineDemo.vbproj* / *CmdLineDemo.csproj*:
 
@@ -121,16 +121,16 @@ Once you have the publish profile created, you can provide the pubxml file as a
 msbuild /target:publish /property:BootstrapperEnabled=false
  ```
 
-For .NET Core 3.1, or later, projects these settings are provided in the pubxml file.
+For .NET projects (.NET Core 3.1, .NET 5, and later), these settings are provided in the pubxml file.
 
  Publishing properties are controlled in [!INCLUDE[vsprvs](../code-quality/includes/vsprvs_md.md)] from the **Publish**, **Security**, and **Signing** property pages of the **Project Designer**. Below is a description of the publishing properties, along with an indication of how each is set in the various property pages of the application designer:
 
 > [!NOTE]
-> For .NET Windows desktop projects, these settings are now found in the Publish Wizard
+> For .NET projects, these settings are now found in the Publish tool.
 
 - `AssemblyOriginatorKeyFile` determines the key file used to sign your [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application manifests. This same key may also be used to assign a strong name to your assemblies. This property is set on the **Signing** page of the **Project Designer**.
 
-For .NET windows applications, this setting remains in the project file
+For .NET windows applications, this setting remains in the project file.
 
   The following properties are set on the **Security** page:
 
@@ -139,7 +139,7 @@ For .NET windows applications, this setting remains in the project file
 - **TargetZone** determines the level of trust to be emitted into your [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application manifest. Possible values are "Internet", "LocalIntranet", and "Custom". Internet and LocalIntranet will cause a default permission set to be emitted into your [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application manifest. LocalIntranet is the default, and it basically means full trust. Custom specifies that only the permissions explicitly specified in the base *app.manifest* file are to be emitted into the [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application manifest. The *app.manifest* file is a partial manifest file that contains just the trust information definitions. It is a hidden file, automatically added to your project when you configure permissions on the **Security** page.
 
 > [!NOTE]
-> For .NET Core 3.1, or later, Windows desktop projects, these Security settings are not supported.
+> For .NET projects, these Security settings are not supported.
 
   The following properties are set on the **Publish** page:
 
@@ -161,15 +161,15 @@ For .NET windows applications, this setting remains in the project file
 
 - `UpdateMode` specifies either Foreground updates or Background updates.
 
-   For .NET Core 3.1, or later, projects, Background is not supported.  
+   For .NET projects (.NET Core 3.1, .NET 5, and later), Background is not supported.  
 
 - `UpdateInterval` specifies how frequently the application should check for updates.
 
-   For .NET Core 3.1, or later, this setting is not supported.
+   For .NET projects, this setting is not supported.
 
 - `UpdateIntervalUnits` specifies whether the `UpdateInterval` value is in units of hours, days, or weeks.
 
-   For .NET Core 3.1, or later, this setting is not supported.
+   For .NET projects, this setting is not supported.
 
 - `UpdateUrl` (not shown) is the location from which the application will receive updates. If specified, this value is inserted into the application manifest.
 

docs/deployment/choosing-a-clickonce-deployment-strategy.md

@@ -42,6 +42,8 @@ There are three different strategies for deploying a [!INCLUDE[ndptecclick](../d
 
  To enable this deployment strategy in [!INCLUDE[vsprvs](../code-quality/includes/vsprvs_md.md)], click **From the Web** or **From a UNC path or file share** on the **How Installed** page of the Publish Wizard.
 
+ [!INCLUDE[ndptecclick](../deployment/includes/dotnet-publish-tool.md)]
+
  This is the default deployment strategy.
 
 ## Start the application from the Web or a network share

docs/deployment/choosing-a-clickonce-update-strategy.md

@@ -71,7 +71,7 @@ ms.workload:
 </subscription>
 ```
 > [!NOTE]
-> For .NET 3.1 and newer applications, checking updates before the application starts is the only update option supported.
+> For .NET Core 3.1 and .NET 5 and newer applications, checking updates before the application starts is the only update option supported.
 
 ## Make updates required
  There may be occasions when you want to require users to run an updated version of your application. For example, you might make a change to an external resource such as a Web service that would prevent the earlier version of your application from working correctly. In this case, you would want to mark your update as required and prevent users from running the earlier version.
@@ -96,6 +96,8 @@ ms.workload:
 
  For example, you may want to check each time the application runs, or one time a week, or one time a month. If a network connection is not present at the specified time, the update check is performed the next time that the application runs.
 
+ [!INCLUDE[ndptecclick](../deployment/includes/dotnet-feature-unsupported.md)]
+
 ## Provide a user interface for updates
  When using this strategy, the application developer provides a user interface that enables the user to choose when or how often the application will check for updates. For example, you might provide a "Check for Updates Now" command, or an "Update Settings" dialog box that has choices for different update intervals. The [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] deployment APIs provide a framework for programming your own update user interface. For more information, see the <xref:System.Deployment.Application> namespace.
 

docs/deployment/clickonce-and-application-settings.md

@@ -28,6 +28,8 @@ Application settings for Windows Forms makes it easy to create, store, and maint
 
  Application settings consumes two files: *\<app>.exe.config* and *user.config*, where *app* is the name of your Windows Forms application. *user.config* is created on the client the first time your application stores user-scoped settings. *\<app>.exe.config*, by contrast, will exist prior to deployment if you define default values for settings. Visual Studio will include this file automatically when you use its **Publish** command. If you create your ClickOnce application using *Mage.exe* or *MageUI.exe*, you must make sure this file is included with your application's other files when you populate your application manifest.
 
+ [!INCLUDE[ndptecclick](../deployment/includes/dotnet-dotnetmage-exe.md)]
+
  In a Windows Forms application not deployed using ClickOnce, an application's *\<app>.exe.config* file is stored in the application directory, while the *user.config* file is stored in the user's **Documents and Settings** folder. In a ClickOnce application, *\<app>.exe.config* lives in the application directory inside of the ClickOnce application cache, and *user.config* lives in the ClickOnce data directory for that application.
 
  Regardless of how you deploy your application, application settings ensures safe read access to *\<app>.exe.config*, and safe read/write access to *user.config*.

docs/deployment/clickonce-deployment-dotnet.md

@@ -0,0 +1,49 @@
+---
+title: ClickOnce for .NET 5 and later on Windows
+description: "Learn about differences between ClickOnce for .NET Core 3.1, .NET 5 and later versus ClickOnce for .NET Framework."
+ms.date: 09/14/2022
+ms.topic: how-to
+helpviewer_keywords:
+  - "deployment, ClickOnce for .NET 5+"
+author: mikejo5000
+ms.author: mikejo
+manager: jmartens
+ms.technology: vs-ide-deployment
+monikerRange: '>= vs-2019'
+ms.workload:
+  - "multiple"
+---
+# ClickOnce for .NET on Windows
+
+ [!INCLUDE [Visual Studio](~/includes/applies-to-version/vs-windows-only.md)]
+
+This article describes the differences between ClickOnce for .NET Core 3.1, .NET 5, and later, versus ClickOnce for .NET Framework.
+
+## Publish tool
+
+Starting in Visual Studio 2019, ClickOnce for .NET Core 3.1 and .NET 5 or later uses the Publish tool instead of the Publish Wizard and properties pages. The Publish tool creates a *.pubxml* file, called a *publish profile*. Most of the properties previously available in the wizard are available to configure in the Publish tool. For detailed instructions, see [Deploy a .NET Windows application using ClickOnce](../deployment/quickstart-deploy-using-clickonce-folder.md).
+
+## MSBUILD
+
+For building from the command line using MSBUILD, you need to specify the *.pubxml* file. For more information, see [Build .NET ClickOnce applications from the command line](../deployment/building-clickonce-applications-from-the-command-line.md#build-net-clickonce-applications-from-the-command-line).
+
+## ApplicationDeployment class
+
+In .NET Core 3.1 and .NET 5 and later, you don't have programmatic access to the <xref:System.Deployment.Application.ApplicationDeployment> class or to other APIs in the <xref:System.Deployment.Application> namespace.
+
+## Mage.exe
+
+In .NET Core 3.1 and .NET 5 and later, use *dotnetmage.exe* instead of [Mage.exe](../deployment/clickonce-security-and-deployment.md#clickonce-tools) to create the ClickOnce deployment.
+
+## Unsupported Publish properties on .NET Core 3.1 and .NET 5 and later
+
+Security settings
+
+- [Enable ClickOnce Security Settings](../deployment/code-access-security-for-clickonce-applications.md) (Code access security)
+- [TargetZone](../deployment/securing-clickonce-applications.md#zones)
+
+Update settings
+
+- [UpdateInterval](../deployment/choosing-a-clickonce-update-strategy.md#specify-update-intervals)
+- [UpdateIntervalUnits](../deployment/choosing-a-clickonce-update-strategy.md#specify-update-intervals)
+- [UpdateMode > Background](../deployment/building-clickonce-applications-from-the-command-line.md#publish-properties)