Merge pull request MicrosoftDocs#4340 from corob-msft/docs/corob/update-deployment

tamarakhader · web-flow · commit 23b8fdaaf950 · 2022-06-08T22:44:00.000-04:00
Update Deployment article per Microsoft Q&amp;A issue
diff --git a/docs/windows/deployment-in-visual-cpp.md b/docs/windows/deployment-in-visual-cpp.md
@@ -1,14 +1,14 @@
 ---
 description: "Learn more about: Deployment in Visual C++"
 title: "Deployment in Visual C++"
-ms.date: 02/07/2022
+ms.date: 06/08/2022
 helpviewer_keywords: ["deploying applications [C++]", "application deployment [C++]"]
 ms.assetid: d4b4ffc0-d2bd-4e4a-84a6-62f1c26f6a09
 ms.custom: intro-deployment
 ---
 # Deployment in Visual C++
 
-Installation of your application on a computer other than your development computer is known as *deployment*. When you deploy a Visual C++ application to another computer, you must install both the application and any library files it depends on. Visual Studio enables three ways to deploy the Visual C++ libraries together with your application: *central deployment*, *local deployment*, and *static linking*. Central deployment puts the library files under the Windows directory, where the Windows Update service can update them automatically. Local deployment puts the library files in the same directory as your application. You must redeploy any locally deployed libraries yourself to update them. Static linking binds the library code into your application. You must recompile and redeploy your application to take advantage of any updates to the libraries when you use static linking.
+Installation of your application on a computer other than your development computer is known as *deployment*. When you deploy a Visual C++ application to another computer, you must install both the application and any library files it depends on. Visual Studio enables three ways to deploy the Visual C++ libraries together with your application: *central deployment*, *local deployment*, and *static linking*. Central deployment puts the library files under the Windows directory, where the Windows Update service can update them automatically. Local deployment puts the library files in the same directory as your application. You must redeploy any locally deployed libraries yourself to update them. Static linking binds the library code into your application. You have to recompile and redeploy your application to take advantage of any updates to the libraries when you use static linking.
 
 In Visual Studio 2015, the Microsoft C Runtime library was refactored into version-specific local library components, and a new Universal C Runtime library that is now part of Windows. For details on deployment of the Universal CRT, see [Universal CRT deployment](universal-crt-deployment.md).
 
@@ -18,27 +18,25 @@ In central deployment, library DLL files are installed in the *`Windows\System32
 
 To centrally deploy Visual C++ libraries, you can use one of these two sources for the files to install:
 
-- *Redistributable package* files. These are stand-alone command-line executables that contain all the Visual C++ Redistributable libraries in compressed form. The latest Redistributable packages are available from [Microsoft Visual C++ Redistributable Latest Supported Downloads](latest-supported-vc-redist.md).
+- *Redistributable package* files. These files are stand-alone command-line executables that contain all the Visual C++ Redistributable libraries in compressed form. The latest Redistributable packages are available from [Microsoft Visual C++ Redistributable Latest Supported Downloads](latest-supported-vc-redist.md).
 
 - *Redistributable merge modules* (*`.msm`* files), which you can include in your application's Windows Installer (*`.msi`*) file. This method is deprecated. For more information, see [Redistributing by using merge modules](redistributing-components-by-using-merge-modules.md).
 
 A Redistributable package file installs all of the Visual C++ libraries for a particular system architecture. For example, if your application is built for x64, you can use the *`vcredist_x64.exe`* package to install all the Visual C++ libraries your application uses. You can program your application installer to run the package as a prerequisite before you install your application.
 
-A merge module enables the inclusion of setup logic for a specific Visual C++ library in a Windows Installer application setup file. You can include as many or as few merge modules as your application requires.
-
-Because central deployment by using a redistributable package or merge modules enables Windows Update to automatically update the Visual C++ libraries, we recommend that you use the library DLLs in your application instead of static libraries, and use central deployment instead of local deployment.
+Central deployment by using a Redistributable package enables Windows Update to automatically update the Visual C++ libraries. For continued security and functionality, we recommend that you use the library DLLs in your application instead of static libraries, and use central deployment instead of local deployment.
 
 ## Local deployment
 
-In local deployment, library files are installed in your application folder together with the executable file. Different versions of Visual C++ redistributable libraries can be installed in the same folder because the file name of each version includes its version number. For example, version 12 of the C++ runtime library is *`msvcp120.dll`*, and version 14 is *`msvcp140.dll`*.
+In local deployment, library files are installed in your application folder together with the executable file. Different versions of Visual C++ Redistributable libraries can be installed in the same folder because the file name of each version includes its version number. For example, version 12 of the C++ runtime library is *`msvcp120.dll`*, and version 14 is *`msvcp140.dll`*.
 
-A library may be spread across multiple additional DLLs, known as *dot libraries*. For example, some functionality in the standard library released in Visual Studio 2017 version 15.6 was added into *`msvcp140_1.dll`*, to preserve the ABI compatibility of *`msvcp140.dll`*. If you use Visual Studio 2017 version 15.6 (toolset 14.13) or later, you may need to locally deploy these dot libraries as well as the main library. These separate dot libraries will eventually be added to the base library, when the ABI changes.
+Expansions to a library may be spread across multiple extra DLLs, known as *dot libraries*. For example, some functionality in the standard library released in Visual Studio 2017 version 15.6 was added into *`msvcp140_1.dll`*, to preserve the ABI compatibility of *`msvcp140.dll`*. If you use Visual Studio 2017 version 15.6 (toolset 14.13) or later, you may need to locally deploy both these dot libraries and the main library. These separate dot libraries will eventually be added to the base library, when the ABI changes.
 
 Because Microsoft can't automatically update locally deployed Visual C++ libraries, we don't recommend local deployment of these libraries. If you decide to use local deployment of the Redistributable libraries, we recommend that you implement your own method of automatically updating the locally deployed libraries.
 
 ## Static linking
 
-In addition to dynamically linked libraries, Visual Studio supplies most of its libraries as static libraries. You can statically link a static library to your application, that is, link the library object code directly into the application. This creates a single binary without a DLL dependency, so that you don't have to deploy the Visual C++ library files separately. However, we don't recommend this approach because statically-linked libraries can't be updated in place. To update a linked library when you use static linking, you have to recompile and redeploy your application.
+In addition to dynamically linked libraries, Visual Studio supplies most of its libraries as static libraries. You can statically link a static library to your application, that is, link the library object code directly into the application. Static linking creates a single binary without a DLL dependency, so that you don't have to deploy the Visual C++ library files separately. However, we don't recommend this approach because statically linked libraries can't be updated in place. To update a linked library when you use static linking, you have to recompile and redeploy your application.
 
 ## Troubleshooting deployment issues
 
diff --git a/docs/windows/redistributing-components-by-using-merge-modules.md b/docs/windows/redistributing-components-by-using-merge-modules.md
@@ -1,30 +1,31 @@
 ---
 description: "Learn more about: Redistributing Components By Using Merge Modules"
 title: "Redistributing Components By Using Merge Modules"
-ms.date: 02/15/2022
+ms.date: 06/08/2022
 helpviewer_keywords: ["merge modules, using", "redistributing applications, using merge modules"]
 ms.assetid: 93b84211-bf9b-4a78-9f22-474ac2ef7840
 ---
 # Redistributing components by using merge modules
 
 > [!IMPORTANT]
-> In Visual Studio 2019 and later, merge modules for Visual C++ Redistributable files are deprecated. We don't recommend you use them for application deployment. Merge modules make it difficult to service Visual C++ Runtime files independently of your application. Instead, we recommend you use central deployment of the Visual C++ Redistributable package. Central deployment installs the Redistributable files in the Windows *`%SYSTEMROOT%\system32\`* folder for use by all applications and users. Central deployment by a Redistributable package makes it possible for Microsoft to service runtime library files independently. And, an uninstall of your app can't break other applications that also use central deployment. When you use a Redistributable package for central deployment, you aren't responsible for tracking and updating the runtime libraries as part of your application maintenance: The Microsoft Update service updates these libraries for you. Otherwise, an update to the runtime library files requires you to update and redeploy your *`.msi`* installer. Your app could be vulnerable to bugs or security issues until you do.
+> In Visual Studio 2019 and later, merge modules for Visual C++ Redistributable files are deprecated. We don't recommend you use them for application deployment. Redistributables installed using Merge modules can't be updated by Windows Update because the detection mechanism depends on knowing details of the installing package. The Visual C++ Redistributable packages are known for each release, but packages that use MSMs are user generated. Microsoft can't know the details of user-generated packages. Instead, we recommend you use central deployment of the Visual C++ Redistributable package. Central deployment installs the Redistributable files in the Windows *`%SYSTEMROOT%\system32\`* folder for use by all applications and users. Central deployment by a Redistributable package makes it possible for Microsoft to service runtime library files independently. And, an uninstall of your app can't break other applications that also use central deployment. When you use a Redistributable package for central deployment, you aren't responsible for tracking and updating the runtime libraries as part of your application maintenance: The Microsoft Update service updates these libraries for you. Otherwise, an update to the runtime library files requires you to update and redeploy your *`.msi`* installer. Your app could be vulnerable to bugs or security issues until you do.
 
 Visual Studio includes [merge modules](/windows/win32/Msi/about-merge-modules) (*`.msm`* files) for each Visual C++ component that's licensed for redistribution with an application. There are separate versions of the merge modules for each target platform. When a merge module is compiled into a Windows Installer setup file, it enables the deployment of Visual C++ Redistributable files to that specific platform. You can't include merge modules for different versions of the same DLL in one installer. In your installer setup file, specify that the merge modules are prerequisites for your application.
 
 You can use merge modules for either [central deployment](deployment-in-visual-cpp.md#central-deployment) or [local deployment](deployment-in-visual-cpp.md#local-deployment). Users can't install centrally deployed files unless they have administrator rights. Local deployment may allow a non-administrator to install and run your app, but at the cost of independent serviceability.
 
 The installation service reports an error if you attempt central deployment of older merge modules over newer existing libraries. You should write your installer setup to handle this failure gracefully and not display an error message. Your code can still deploy and run successfully despite this failure. For more information, see [C++ binary compatibility between Visual Studio versions](../porting/binary-compat-2015-2017.md).
 
-If you deploy your code only as an *`.msi`* installer, we recommend you don't include the merge modules in the installer. Instead, report a failure to the user when the required Redistributable libraries aren't found. In the failure dialog, include instructions on how to find and install the latest Redistributable package.
+If you deploy your code only as an *`.msi`* installer, we recommend you don't include the merge modules in the installer. Instead, report a failure to the user when the required Redistributable libraries aren't found. In the failure dialog, include instructions on how to find and install the latest Redistributable package. For more information and links to Redistributable packages, see [The latest supported Visual C++ downloads](latest-supported-vc-redist.md).
 
-The latest Redistributable packages and merge modules are compatible with code built using Visual Studio 2015 and later. Code built by versions of Visual Studio before 2015 require a separate Redistributable package. For more information and links to Redistributable packages, see [The latest supported Visual C++ downloads](latest-supported-vc-redist.md).
+The latest Redistributable packages and merge modules are compatible with code built using Visual Studio 2015 and later. Code built by versions of Visual Studio before 2015 require a separate Redistributable package.
 
 ## When to use merge modules
 
 Merge modules are only appropriate in limited circumstances:
 
 - You can't install or require a separate Redistributable package for policy reasons,
+- Your code requires a specific, bug-compatible version of the libraries,
 - Your code only targets one platform, and you don't have dependencies on more than one version of the DLLs,
 - You intend to service your deployed code regularly, so the libraries remain up to date.
 
