Finished reviewing /porting for VS 2026 and updating MSVC branding

Author: AugP

docs/porting/binary-compat-2015-2017.md

@@ -6,20 +6,20 @@ helpviewer_keywords: ["binary compatibility, Visual C++"]
 ---
 # C++ binary compatibility between Visual Studio versions
 
-The Microsoft C++ (MSVC) Build Tools in Visual Studio 2013 and earlier don't guarantee binary compatibility across major versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions of these toolsets. The ABIs, object formats, and runtime libraries are incompatible.
+The Microsoft C++ (MSVC) Build Tools in Visual Studio 2013 and earlier don't guarantee binary compatibility across major versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions of these build tools. The ABIs, object formats, and runtime libraries are incompatible.
 
-We've changed this behavior in Visual Studio 2015 and later versions. The runtime libraries and apps compiled by any of these versions of the compiler are binary-compatible. It's reflected in the C++ toolset major number, which starts with 14 for all versions since Visual Studio 2015. (The toolset version is v140 for Visual Studio 2015, v141 for 2017, v142 for 2019, and v143 for 2022). Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017, 2019, 2022, or 2026. There's no need to recompile with a matching toolset. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
+We've changed this behavior in Visual Studio 2015 and later versions. The runtime libraries and apps compiled by any of these versions of the compiler are binary-compatible. It's reflected in the MSVC Build Tools major number, which starts with 14 for all versions since Visual Studio 2015. (The build tools version is v140 for Visual Studio 2015, v141 for 2017, v142 for 2019, and v143 for 2022). Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017, 2019, 2022, or 2026. There's no need to recompile with a matching version. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
 
 ## <a name="restrictions"></a> Restrictions on binary compatibility
 
-There are three important restrictions on binary compatibility between the v140, v141, v142, v143, and v145 toolsets and minor numbered version updates:
+There are three important restrictions on binary compatibility between the v140, v141, v142, v143, and v145 build tools and minor numbered version updates:
 
-- Binaries created with different versions of the v140, v141, v142, v143, and v145 toolsets can be combined. The key rule is that the linker should only work with inputs built by a toolset that is the same version (or earlier) as itself. This applies to apps, import libraries, static libraries, and other files as described in [LINK input files](../build/reference/link-input-files.md). In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means:
-    - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2022 version 17.8 (v143), but the linking must be done using a version 17.8 or later toolset.
-    - Apps and libraries built using VS 2015, 2017, 2019, 2022, and 2026 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries you pass to the linker. For example, given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.9, and VS 2019 version 16.11, you can link them using any toolset version that is 16.11 or later.
-    - If a DLL is built with a newer toolset, the import library can sometimes be used with older toolsets if all of the exports follow the C language calling convention (`extern "C"`). However, the only officially supported case is consuming a newer windows SDK with an older toolset.
-- The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.
-- Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md).
+- Binaries created with different versions of the v140, v141, v142, v143, and v145 build tools can be combined. The key rule is that the linker should only work with inputs built by build tools that are the same version (or earlier) as itself. This applies to apps, import libraries, static libraries, and other files as described in [LINK input files](../build/reference/link-input-files.md). In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the build tools can be linked using an earlier version of the build tools--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means:
+    - An app compiled with the 2017 build tools (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2022 version 17.8 (v143), but the linking must be done using a version 17.8 or later build tools.
+    - Apps and libraries built using VS 2015, 2017, 2019, 2022, and 2026 can be linked together, but the linking must be done using a version of the build tools that is as recent as, or more recent than, the most recent build tools used to build any of the binaries you pass to the linker. For example, given three binaries built with build tools from VS 2015 version 14.3, VS 2017 version 15.9, and VS 2019 version 16.11, you can link them using any build tools version that is 16.11 or later.
+    - If a DLL is built with newer build tools, the import library can sometimes be used with older build tools if all of the exports follow the C language calling convention (`extern "C"`). However, the only officially supported case is consuming a newer windows SDK with older build tools.
+- The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the build tools, the Redistributable version must be at least as new as the latest build tools used by any app component.
+- Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same build tools for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 build tools can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 build tools. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md).
 
 ## Upgrade the Microsoft Visual C++ Redistributable from Visual Studio 2015 and later
 

docs/porting/build-system-changes.md

@@ -7,7 +7,7 @@ ms.assetid: e564d95f-a6cc-4d97-b57e-1a71daf66f4a
 ---
 # VCBuild vs. MSBuild: Build system changes in Visual Studio 2010
 
-The MSBuild system for C++ projects was introduced in Visual Studio 2010. In Visual Studio 2008 and earlier releases, the VCBuild system was used. Certain file types and concepts that depended on VCBuild either do not exist or are represented differently in MSBuild. This document discusses the differences in the current build system. To convert a Visual Studio 2008 project to MSBuild, you must use Visual Studio 2010. After the project is converted, you should use the latest version of Visual Studio to upgrade to the current IDE and compiler toolset. For more information, including how to obtain Visual Studio 2010, see [Instructions for Visual Studio 2008](use-native-multi-targeting.md#instructions-for-visual-studio-2008).
+The MSBuild system for C++ projects was introduced in Visual Studio 2010. In Visual Studio 2008 and earlier releases, the VCBuild system was used. Certain file types and concepts that depended on VCBuild either do not exist or are represented differently in MSBuild. This document discusses the differences in the current build system. To convert a Visual Studio 2008 project to MSBuild, you must use Visual Studio 2010. After the project is converted, you should use the latest version of Visual Studio to upgrade to the current IDE and build tools. For more information, including how to obtain Visual Studio 2010, see [Instructions for Visual Studio 2008](use-native-multi-targeting.md#instructions-for-visual-studio-2008).
 
 The following sections summarize the changes from VCBuild to MSBuild. If your VCBuild project has custom build rules or macros that aren't recognized by MSBuild, see [Visual Studio Projects - C++](../build/creating-and-managing-visual-cpp-projects.md) to learn how to translate those instructions to the MSBuild system. The initial conversion from VCBuild to MSBuild is just an intermediate step. It isn't necessary to get the project file completely correct or to get the program to compile without errors. You are only using Visual Studio 2010 to convert the project to MSBuild format so that you get the project working in the latest version of Visual Studio.
 

docs/porting/features-deprecated-in-visual-studio.md

@@ -12,7 +12,7 @@ This article is a non-exhaustive list of C++ features deprecated in Visual Studi
 
 ### Support for Windows XP development
 
-Visual Studio 2019 and later versions don't include current toolset support for creating code for Windows XP. Support for Windows XP development by using the v141_xp toolset that shipped in Visual Studio 2017 is still available as an optional component in the Visual Studio Installer. For information on how to install the v141_xp Windows XP platform toolset, see [Configuring programs for Windows XP](../build/configuring-programs-for-windows-xp.md).
+Visual Studio 2019 and later versions don't include current build tools support for creating code for Windows XP. Support for Windows XP development by using the v141_xp build tools that shipped in Visual Studio 2017 is still available as an optional component in the Visual Studio Installer. For information on how to install the v141_xp Windows XP platform toolset, see [Configuring programs for Windows XP](../build/configuring-programs-for-windows-xp.md).
 
 ## Visual Studio 2022
 

docs/porting/floating-point-migration-issues.md

@@ -22,7 +22,7 @@ Code-generation correctness improvements in different floating point modes in Vi
 
 ## How to get identical results
 
-In most cases, the floating-point changes in the newest compilers and libraries result in faster or more correct behavior, or both. You may even see better processor power performance when SSE2 instructions replace x87 instructions. However, if you have code that must precisely replicate the floating point behavior of an older compiler, consider using Visual Studio native multi-targeting capabilities, and build the affected project with the older toolset. For more information, see [Use native multi-targeting in Visual Studio to build old projects](use-native-multi-targeting.md).
+In most cases, the floating-point changes in the newest compilers and libraries result in faster or more correct behavior, or both. You may even see better processor power performance when SSE2 instructions replace x87 instructions. However, if you have code that must precisely replicate the floating point behavior of an older compiler, consider using Visual Studio native multi-targeting capabilities, and build the affected project with the older build tools. For more information, see [Use native multi-targeting in Visual Studio to build old projects](use-native-multi-targeting.md).
 
 ## See also
 

docs/porting/ide-tools-for-upgrading-code.md

@@ -1,14 +1,14 @@
 ---
 title: "Visual Studio IDE tools for upgrading C++ code"
 description: "The C++ code editor and code analysis tools in Visual Studio help you to modernize your C++ code base."
-ms.date: "11/13/2019"
+ms.date: "11/06/2025"
 ms.topic: "concept-article"
 ---
 # Visual Studio IDE tools for upgrading C++ code
 
 Visual Studio helps you upgrade legacy C++ code with compiler options, code analysis warnings, and editor features such as Quick Fixes, Quick Info, and the enhanced scroll bar. The term "legacy code" refers to any of these categories:
 
-- Code that was formerly allowed by the Microsoft C++ compiler (MSVC) but never conformed to the C++ standard.
+- Code that was formerly allowed by the Microsoft C++ (MSVC) compiler but never conformed to the C++ standard.
 
    To upgrade older non-conforming MSVC code, turn on the [`/permissive-`](../build/reference/permissive-standards-conformance.md) compiler option. All instances of non-conforming usages are underlined with red squiggles in the code editor. The error messages in the **Error List** window include a recommendation for how to fix the error. Click on the error code to go to its help page in the documentation. If fixing all the errors at once is impractical, you can upgrade non-conforming code in stages by turning on the **`/permissive-`** option, fixing some errors, then turning the option off again. The code will compile with the new improvements, and you can go back and fix the remaining issues at a later time. See the [`/permissive-`](../build/reference/permissive-standards-conformance.md) page for examples of non-conforming MSVC code.
 
@@ -22,19 +22,15 @@ Visual Studio helps you upgrade legacy C++ code with compiler options, code anal
 
 ## Open and convert a legacy project
 
-If your legacy project is based on an older version of Visual Studio, you can open it in Visual Studio 2017 or Visual Studio 2019. Visual Studio automatically converts it to the current project schema with support for all the latest compiler and IDE features.
+If your legacy projects are based on an older version of Visual Studio, you can still load them in a newer version and work on it there while maintaining backwards compatibility with the older version. When you are ready to permanently move to the new version of Visual Studio, you can retarget your projects. This will enable you to use the latest build tools and project features in the IDE, but you will no longer be able to load the retargeted projects in the older version of Visual Studio.
 
-![Screenshot of the Upgrade a project dialog.](media/upgrade-dialog-v142.png "Upgrade a project")
+To retarget projects to the Visual Studio 2026 format, you can use the setup assistant which appears the first time you open a solution with older projects. You can also access it by right-clicking the solution in Solution Explorer and selecting *Retarget solution*.
 
-For more information, see [Upgrade C++ projects from earlier versions of Visual Studio](upgrading-projects-from-earlier-versions-of-visual-cpp.md).
-
-## Search the code base
+![Screenshot of the Visual Studio 2026 setup assistant.](media/vs-2026-setup-assistant.png "Upgrade projects")
 
-Upgrading a code base often involves searching through multiple files. To search for anything in your code base, press **Ctrl+T** to bring up the **Go to All** search box.
+The setup assistant then gives you the choice to either stay on the older version and install any missing build tools or Windows SDKs to be able to build, or retarget the projects to upgrade them. You can make retargeting selections for each project in the solution or click *Retarget all*, then click *Apply* to perform the upgrade.
 
-![Screenshot of the Go to all dialog.](media/go-to-all.png "Go to all")
-
-To narrow the search scope, type one of the 1-letter filters, followed by a space and then the thing you are looking for.
+For more information, see [Upgrade C++ projects from earlier versions of Visual Studio](upgrading-projects-from-earlier-versions-of-visual-cpp.md).
 
 ## Error List
 

docs/porting/media/vs-2026-setup-assistant.png

@@ -8,7 +8,7 @@ ms.topic: how-to
 ---
 # Update WINVER and _WIN32_WINNT
 
-When you use the Windows SDK, you can specify which versions of Windows your code can run on. The preprocessor macros **WINVER** and **_WIN32_WINNT** specify the minimum operating system version your code supports. Visual Studio and the Microsoft C++ compiler support targeting Windows 7 SP1 and later. Older toolsets include support for Windows XP SP2, Windows Server 2003 SP1, Vista, and Windows Server 2008. Windows 95, Windows 98, Windows ME, Windows NT, and Windows 2000 are unsupported.
+When you use the Windows SDK, you can specify which versions of Windows your code can run on. The preprocessor macros **WINVER** and **_WIN32_WINNT** specify the minimum operating system version your code supports. Visual Studio and the Microsoft C++ compiler support targeting Windows 7 SP1 and later. Older build tools include support for Windows XP SP2, Windows Server 2003 SP1, Vista, and Windows Server 2008. Windows 95, Windows 98, Windows ME, Windows NT, and Windows 2000 are unsupported.
 
 When you upgrade an older project, you may need to update your **WINVER** or **_WIN32_WINNT** macros. If they're assigned values for an unsupported version of Windows, you may see compilation errors related to these macros.