Merge pull request #14203 from MicrosoftDocs/main

Auto Publish – main to live - 2025-08-13 22:30 UTC

Author: learn-build-service-prod[bot]

docs/ide/mcp-servers.md

@@ -16,7 +16,7 @@ monikerRange: '>= vs-2022'
 Model Context Protocol (MCP) is an open standard that enables AI models to interact with external tools and services through a unified interface. In Visual Studio, MCP support enhances GitHub Copilot's agent mode by allowing you to connect any MCP-compatible server to your agentic coding workflow. This article guides you through setting up MCP servers and using tools with agent mode in Visual Studio.
 
 ## Prerequisites
-+ [Visual Studio 2022 version 17.14](/visualstudio/releases/2022/release-history) or later.
++ [Visual Studio 2022 version 17.14](/visualstudio/releases/2022/release-history) or later. The latest servicing release of 17.14 is highly recommended as MCP features are actively being added with each release.
 
 ## How do MCP and Visual Studio extend GitHub Copilot's agent?
 
@@ -30,54 +30,33 @@ By standardizing this interaction, MCP eliminates the need for custom integratio
 
 ## Configuration example with GitHub MCP server
 
-1. Create a new file: `<SOLUTIONDIR>\.mcp.json`. Using Visual Studio to edit this file is recommended so its JSON schema is automatically applied.
+The following walkthrough requires 17.14.9 or later.
+
+1. Create a new file: `<SOLUTIONDIR>\.mcp.json` or `%USERPROFILE%\.mcp.json`. Using Visual Studio to edit this file is recommended so its JSON schema is automatically applied.
 2. Paste the following contents into the `.mcp.json` file
 
   ```json
   {
-    "inputs": [
-      {
-        "id": "github_pat",
-        "description": "GitHub personal access token",
-        "type": "promptString",
-        "password": true
-      }
-    ],
     "servers": {
       "github": {
-        "type": "stdio",
-        "command": "docker",
-        "args": [
-          "run",
-          "-i",
-          "--rm",
-          "-e",
-          "GITHUB_PERSONAL_ACCESS_TOKEN",
-          "ghcr.io/github/github-mcp-server"
-        ],
-        "env": {
-          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_pat}"
-        }
+        "url": "https://api.githubcopilot.com/mcp/"
       }
     }
   }
   ```
 
-3. Get a Personal Access Token for your [GitHub Account](https://github.com/settings/personal-access-tokens)
-4. In Visual Studio, click the `Ask` dropdown in the GitHub Copilot Chat window, and then select `Agent`.
+3. Save the file, then activate the CodeLens that appears over the new server to authenticate to this server using a GitHub account.
 
-    :::image type="content" source="media/vs-2022/copilot-agent-mode/copilot-agent-dropdown.png" alt-text="Screenshot that shows Copilot agent mode selector." lightbox="media/vs-2022/copilot-agent-mode/copilot-agent-dropdown.png":::
+5. In Visual Studio, click the `Ask` dropdown in the GitHub Copilot Chat window, and then select `Agent`.
 
-5. When prompted, paste your personal access token into the dialog.
-
-    :::image type="content" source="media/vs-2022/mcp-servers/model-context-protocol-personal-access-token.png" alt-text="Screenshot that shows entering the personal access token." lightbox="media/vs-2022/mcp-servers/model-context-protocol-personal-access-token.png":::
+    :::image type="content" source="media/vs-2022/copilot-agent-mode/copilot-agent-dropdown.png" alt-text="Screenshot that shows Copilot agent mode selector." lightbox="media/vs-2022/copilot-agent-mode/copilot-agent-dropdown.png":::
 
-6. Select the tools you'd like to use, for example, `list_issues`
+7. Select the tools you'd like to use, for example, `list_issues`
 
     :::image type="content" source="media/vs-2022/mcp-servers/model-context-protocol-github-tools-list.png" alt-text="Screenshot that shows MCP GitHub tools." lightbox="media/vs-2022/mcp-servers/model-context-protocol-github-tools-list.png":::
 
-7. Try a sample prompt: `list issues assigned to me on GitHub`
-8. Copilot asks for permission to use a tool made available to it by the MCP server, select **Allow** with the scope you wish to proceed with.
+8. Try a sample prompt: `list issues assigned to me on GitHub`
+9. Copilot asks for permission to use a tool made available to it by the MCP server, select **Allow** with the scope you wish to proceed with.
 
     :::image type="content" source="media/vs-2022/copilot-agent-mode/copilot-agent-tool-approval.png" alt-text="Screenshot that shows the agent tools confirmation options." lightbox="media/vs-2022/copilot-agent-mode/copilot-agent-tool-approval.png":::
 

docs/msbuild/comparing-properties-and-items.md

@@ -74,7 +74,7 @@ Properties are passed to tasks as attributes. Within the task, an MSBuild proper
 
 Items are passed to tasks as <xref:Microsoft.Build.Framework.ITaskItem> objects. Within the task, <xref:Microsoft.Build.Framework.ITaskItem.ItemSpec%2A> represents the value of the item and <xref:Microsoft.Build.Framework.ITaskItem.GetMetadata%2A> retrieves its metadata.
 
-The item list of an item type can be passed as an array of `ITaskItem` objects. Beginning with the .NET Framework 3.5, items can be removed from an item list in a target by using the `Remove` attribute. Because items can be removed from an item list, it is possible for an item type to have zero items. If an item list is passed to a task, the code in the task should check for this possibility.
+The item list of an item type can be passed as an array of `ITaskItem` objects. Items can be removed from an item list in a target by using the `Remove` attribute. Because items can be removed from an item list, it is possible for an item type to have zero items. If an item list is passed to a task, the code in the task should check for this possibility.
 
 ## Property and item evaluation order
 

docs/msbuild/configure-tasks.md

@@ -12,13 +12,13 @@ ms.subservice: msbuild
 
 You can configure MSBuild targets and tasks to run out-of-process with MSBuild so that you can run tasks in contexts that differ from the one running the overall build. This can be useful when running tasks that are not compatible with 64-bit MSBuild and when targeting a different version of .NET Framework. 
 
-For example, you can target a 32-bit .NET Framework 2.0 application while the development computer is running on a 64-bit .NET Framework 4.5 operating system. You can also target computers that run with the .NET Framework 4 or earlier. The combination of 32- or 64-bitness and the specific .NET Framework version is known as the *target context*.
+For example, you can target a 32-bit .NET Framework 3.5 SP1 application while the development computer is running on a 64-bit .NET Framework 4.7.2 operating system. The combination of 32- or 64-bitness and the specific .NET Framework version is known as the *target context*.
 
 ## Tasks
 
- MSBuild runs certain build tasks out of process to target a larger set of contexts.  For example, a 32-bit MSBuild might run a build task in a 64-bit process. This is controlled by `UsingTask` arguments and `Task` parameters. The targets installed by the .NET Framework 4.5 set these arguments and parameters, and no changes are required to build applications for the various target contexts.
+ MSBuild runs certain build tasks out of process to target a larger set of contexts.  For example, a 32-bit MSBuild might run a build task in a 64-bit process. This is controlled by `UsingTask` arguments and `Task` parameters. The targets installed with MSBuild set these arguments and parameters, and no changes are required to build applications for the various target contexts.
 
- If you want to create your own target context, you must set these arguments and parameters appropriately. Look in the .NET Framework 4.5 *Microsoft.Common.targets* file and the *Microsoft.Common.Tasks* file for examples.  For information about how to create a custom task that can work with multiple target contexts, or how to modify existing tasks, see [How to: Configure targets and tasks](../msbuild/how-to-configure-targets-and-tasks.md).
+ If you want to create your own target context, you must set these arguments and parameters appropriately. Look in the *Microsoft.Common.targets* file and the *Microsoft.Common.Tasks* file for examples.  For information about how to create a custom task that can work with multiple target contexts, or how to modify existing tasks, see [How to: Configure targets and tasks](../msbuild/how-to-configure-targets-and-tasks.md).
 
 ## Errors arising from incorrect configuration
 

docs/msbuild/customize-by-directory.md

@@ -126,7 +126,7 @@ A summary of MSBuild's general approach is as follows:
 - For any given project, MSBuild finds the first *Directory.Build.props* upward in the solution structure, merges it with defaults, and stops scanning for more.
 - If you want multiple levels to be found and merged, then [`<Import...>`](../msbuild/property-functions.md#msbuild-getpathoffileabove) (shown previously) the "outer" file from the "inner" file.
 - If the "outer" file doesn't itself also import something above it, then scanning stops there.
-- Only do this if the uupper level file actual exists
+- Only do this if the outer file actually exists
 
 Or more simply: the first *Directory.Build.props* that doesn't import anything is where MSBuild stops.
 

docs/msbuild/generatebootstrapper-task.md

@@ -148,27 +148,22 @@ In addition to the parameters listed above, this task inherits parameters from t
 
 ## Example
 
-The following example uses the `GenerateBootstrapper` task to install an application that must have the .NET Framework 2.0 installed as a prerequisite.
+The following example uses the `GenerateBootstrapper` task to install an application that must have the .NET Framework 4.8 installed as a prerequisite.
 
 ```xml
-<Project>
-
-    <ItemGroup>
-        <BootstrapperFile Include="Microsoft.Net.Framework.2.0">
-            <ProductName>Microsoft .NET Framework 2.0</ProductName>
-        </BootstrapperFile>
-    </ItemGroup>
-
-    <Target Name="BuildBootstrapper">
-        <GenerateBootstrapper
-            ApplicationFile="WindowsApplication1.application"
-            ApplicationName="WindowsApplication1"
-            ApplicationUrl="http://mycomputer"
-            BootstrapperItems="@(BootstrapperFile)"
-            OutputPath="C:\output" />
-    </Target>
-
-</Project>
+<ItemGroup>
+  <BootstrapperFile Include="Microsoft.Net.Framework.4.8">
+    <ProductName>.NET Framework 4.8</ProductName>
+  </BootstrapperFile>
+</ItemGroup>
+
+<Target Name="CustomBootstrapper">
+  <GenerateBootstrapper
+    ApplicationFile="MyApp.exe"
+    BootstrapperItems="@(BootstrapperFile)"
+    OutputPath="$(OutputPath)"
+    ComponentsLocation="Relative" />
+</Target>
 ```
 
 ## See also

docs/msbuild/import-element-msbuild.md

@@ -71,7 +71,7 @@ Imports the contents of one project file into another project file.
 
 ## Wildcards
 
- In the .NET Framework 4, MSBuild allows wildcards in the Project attribute. When there are wildcards, all matches found are sorted (for reproducibility), and then they are imported in that order as if the order had been explicitly set.
+ MSBuild allows wildcards in the Project attribute. When there are wildcards, all matches found are sorted (for reproducibility), and then they are imported in that order as if the order had been explicitly set.
 
  This is useful if you want to offer an extensibility point so that someone else can import a file without requiring you to explicitly add the file name to the importing file. For this purpose, *Microsoft.Common.Targets* contains the following line at the top of the file.
 

docs/msbuild/itemgroup-element-msbuild.md

@@ -58,7 +58,7 @@ In addition to the generic `Item` element, ItemGroup allows child elements that
 | Element | Description |
 | - | - |
 | [Project](../msbuild/project-element-msbuild.md) | Required root element of an MSBuild project file. |
-| [Target](../msbuild/target-element-msbuild.md) | Starting with .NET Framework 3.5, the `ItemGroup` element can appear inside a `Target` element. For more information, see [Targets](../msbuild/msbuild-targets.md). |
+| [Target](../msbuild/target-element-msbuild.md) | The `ItemGroup` element can appear inside a `Target` element. For more information, see [Targets](../msbuild/msbuild-targets.md). |
 
 ## Example
 

docs/msbuild/msbuild-multitargeting-overview.md

@@ -10,16 +10,14 @@ ms.subservice: msbuild
 ---
 # Target multiple framework versions and platforms
 
-By using MSBuild, you can compile an application to run on any one of several versions of the .NET Framework, and on any one of several system platforms. For example, you can compile an application to run on the .NET Framework 2.0 on a 32-bit platform, and compile the same application to run on the .NET Framework 4.5 on a 64-bit platform.
+By using MSBuild, you can compile an application to run on any one of several versions of the .NET Framework, and on any one of several system platforms. For example, you can compile an application to run on the .NET Framework 3.5 SP1 on a 32-bit platform, and compile the same application to run on the .NET Framework 4.7.2 on a 64-bit platform.
 
 > [!NOTE]
 > This article describes an older type of multitargeting that applies to .NET Framework builds in which a project can target only one framework and only one platform at a time. In .NET Core and .NET 5 and later, you can use a newer type of multitargeting by using the `TargetFrameworks` (plural) property in a project file. When you build with `dotnet build` or similar .NET CLI commands, or with Visual Studio after reloading the project, your build uses the newer type of multitargeting, in which multiple builds occur, once for each target framework listed. See [Target frameworks](/dotnet/standard/frameworks).
 
  These are some of the features of MSBuild targeting:
 
-- You can develop an application that targets an earlier version of the .NET Framework, for example, versions 2.0, 3.5, or 4.
-
-- You can target a framework other than the .NET Framework, for example, the Silverlight Framework.
+- You can develop an application that targets an earlier version of the .NET Framework, for example, version 3.5 SP1.
 
 - You can target a *framework profile*, which is a predefined subset of a target framework.
 
@@ -29,19 +27,19 @@ By using MSBuild, you can compile an application to run on any one of several ve
 
 ## Target framework and platform
 
- A *target framework* is the version of the .NET Framework that a project is built to run on, and a *target platform* is the system platform that the project is built to run on.  For example, you might want to target a .NET Framework 2.0 application to run on a 32-bit platform that is compatible with the 80x86 processor family (x86). The combination of target framework and target platform is known as the *target context*. For more information, see [Target framework and target platform](../msbuild/msbuild-target-framework-and-target-platform.md).
+ A *target framework* is the version of the .NET Framework that a project is built to run on, and a *target platform* is the system platform that the project is built to run on.  For example, you might want to target a .NET Framework 3.5 SP1 application to run on a 32-bit platform that is compatible with the 80x86 processor family (x86). The combination of target framework and target platform is known as the *target context*. For more information, see [Target framework and target platform](../msbuild/msbuild-target-framework-and-target-platform.md).
 
 ## Toolset (ToolsVersion)
 
- A Toolset collects together the tools, tasks, and targets that are used to create the application. A Toolset includes compilers such as *csc.exe* and *vbc.exe*, the common targets file (*microsoft.common.targets*), and the common tasks file (*microsoft.common.tasks*). The 4.5 Toolset can be used to target .NET Framework versions 2.0, 3.0, 3.5, 4, and 4.5. However, the 2.0 Toolset can only be used to target the .NET Framework version 2.0. For more information, see [Toolset (ToolsVersion)](../msbuild/msbuild-toolset-toolsversion.md).
+ A Toolset collects together the tools, tasks, and targets that are used to create the application. A Toolset includes compilers such as *csc.exe* and *vbc.exe*, the common targets file (*microsoft.common.targets*), and the common tasks file (*microsoft.common.tasks*). For more information, see [Toolset (ToolsVersion)](../msbuild/msbuild-toolset-toolsversion.md).
 
 ## Reference assemblies
 
  The reference assemblies that are specified in the Toolset help you design and build an application. These reference assemblies not only enable a particular target build, but also restrict components and features in the Visual Studio IDE to those that are compatible with the target. For more information, see [Resolve assemblies at design time](../msbuild/resolving-assemblies-at-design-time.md).
 
 ## Configure targets and tasks
 
- You can configure MSBuild targets and tasks to run out-of-process with MSBuild so that you can target contexts that are considerably different than the one you are running on.  For example, you can target a 32-bit, .NET Framework 2.0 application while the development computer is running on a 64-bit platform with .NET Framework 4.5. For more information, see [Configure targets and tasks](../msbuild/configure-tasks.md).
+ You can configure MSBuild targets and tasks to run out-of-process with MSBuild so that you can target contexts that are considerably different than the one you are running on.  For example, you can target a 32-bit, .NET Framework 3.5 SP1 application while the development computer is running on a 64-bit platform with .NET Framework 4.7.2. For more information, see [Configure targets and tasks](../msbuild/configure-tasks.md).
 
 ## Troubleshooting
 

docs/msbuild/msbuild-target-framework-and-target-platform.md

@@ -19,7 +19,7 @@ A project can be built to run on a *target framework*, which is a particular ver
 
  A target framework is the particular version of the .NET Framework that your project is built to run on. Specification of a target framework is required because it enables compiler features and assembly references that are exclusive to that version of the framework.
 
- Currently, the following versions of the .NET Framework are available for use:
+ Currently, the following versions of the .NET Framework are available for use, although some are no longer supported by Microsoft, and some have planned future dates beyond which they will no longer be supported. For the latest support information, see [.NET Framework](/lifecycle/products/microsoft-net-framework):
 
 - The .NET Framework 2.0 (included in Visual Studio 2005)