C++ App Deployment - VCRT Installation using Merge Module versus redistributable package

Question

I am wanting to deploy my application but I am stuck on the decision on how to install the VCRT on the client machine. The Microsoft Learn tells me that "Merge modules (.msm files) for Visual C++ Redistributable files are deprecated." because "Central deployment by a Redistributable package makes it possible for Microsoft to service runtime library files independently.". When I install my application plus the VCRT with merge modules, the VCRT files appear to be placed in C:/Windows/System32. However, when I install the VCRT separately with a redistributable package the files are placed also in C:/Windows/System32.

My question is: Why is it that the VCRT files cannot be updated by Microsoft when I install the VCRT using merge modules even though the files end up in the same folder in both cases?

My IDE is Visual Studio 2022.

Answer 1

If I understand the Questioner correctly the issue is about deploying the VC++ runtime libraries as part of deploying an application, not installing Visual Studio. This is posted as an Answer due to the 1600 character limit for comments.

The guidance on deploying the VC++ runtime using the redistributables or merge modules is ambiguous and confusing.

The guidance at https://learn.microsoft.com/en-us/cpp/windows/deployment-in-visual-cpp?view=msvc-170 states -

"Central deployment puts the library files under the Windows directory, where the Windows Update service can update them automatically."

The above documentation also says the following about Central deployment -

"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.  

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."  

So it can be concluded that using merge modules still allows for Windows Update to service the VC++ libraries.

However this guidance is made unclear by the documentation at https://learn.microsoft.com/en-us/cpp/windows/redistributing-components-by-using-merge-modules?view=msvc-170 which states

"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."

This is an apparent contradiction of the earlier guidance which indicates that merge modules can be used for Central deployment.

Answer 2

Thanks for the answers.

Basically I am just looking for more clearance on why installing VC++ libraries via Merge Modules is discouraged and central deployment is preferred.

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.

Source: https://learn.microsoft.com/en-us/cpp/windows/redistributing-components-by-using-merge-modules?view=msvc-170

I am looking to get a better answer on WHY the merge modules way makes it difficult to service runtime files independently.

As far as I have seen, when I install VC++ libraries via Merge Modules the files also get installed in the System32 folder. That is why I don't understand why "central deployment" allows for updates and the merge module way does not, even though the files end up in the same folder.

Answer 3

Microsoft can update the VC Redistributable packages via Windows Update for critical security vulnerabilities. While MSMs cannot be updated via Windows Update because the detection mechanism depends on details of the installing package. While the VC Redistributable packages are known for each release, the packages that use MSMs are user generated. The details of those packages are not known to Microsoft.

The deprecation and removal of MSMs is proceeding. We are working on developing viable solutions for those that, for whatever reason, cannot use the VC Redistributable installers, as a replacement for MSMs.
Until those are developed, it is recommended that, instead of MSMs, app-local deployment of runtime binaries be used if the VC Redistributable cannot be used in your project.