Change in recommendation for redistributing Visual C++ libraries?

Question

Hello,

I'm about to switch from statically linking the C++ libraries in my application to using dynamic linking. Because of this I'm trying to decide the best method for redistributing/installing the Visual C++ libraries needed. I am using Visual Studio 2010 and I have consulted the "Choosing a deployment method" MSDN documentation for guidance. This article says that using the redistributable package is the recommended way of doing it. But when I look at the corresponding documentation for Visual Studio 2008 (here) I get the impression that this recommends using the merge modules. The article "How to redistribute the Visual C++ Libraries with your application", which deals with VS2008 also prefers the merge modules.

I realize that I'm supposed to follow the recommendation for my particular version but I still feel I need to know more here to make the right decision.

So... My questions are: Is it correct that the recommendations has changed? If so, why?

Thanks in advance!

Johan

Answer 1

There is no "official" recommendation. The author always has their own personal biases when it comes to matters such as this. The most common rationale for switching to a DLL is to permit updates to take place to the DLL's through Windows Update, and presumably close any security holes. My own experience has been the occasional, albeit rare time when the update is buggy and a perfectly solid application suddenly blows up. (Yes that was 10 years ago, but the bitter taste lingers). Personally, I recommend static linking which is impervious to this problem.

So listen to your inner heart. Why do you want to convert to a DLL configuration? What do you expect to gain from this effort?

Answer 2

Thanks for your answer Brian!

I realize that there are many opinions regarding this issue but I did not perceive the MSDN documentation as being biased in that way. The blog article (for which I forgot to supply the link: here it is), I realize, is another matter and I assumed personal opinions there. So I'm still interested to know why the method recommendations has changed in the MSDN documentation. But as you say: Maybe they are also influenced by the writers opinion?

When it comes to switching or not I have no choice. Parts of the application will require CLR support which, from what I understand, brings the dynamic linking as a requirement.

Answer 3

There is a change - SXS for VC redist was dropped in VS2010 - that could lead to the change in documentation but my favorite is always merge modules.

There are too many questions here on "how many VC redist do I need" from end users already. And VC redists are not reference counted, if you use it, you app risk being broken by accidental uninstallation of VC redist by one of the confused users. I think it should only be used by apps that are not installed via Windows Installer, such as ClickOnce deployment. Besides, there are many threads on Microsoft Answer's Windows Update forum on problem with updating the VC redist. 

Xcopy deployment and static link are safe, assuming you update your app after Microsoft releases security updates, but also need extra disk space, sometimes a problem for SSD disks. 

---

The following is signature, not part of post
Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
Visual C++ MVP

Answer 4

On 06/03/2012 21:17, Brian Muth [MVP] wrote:

The most common rationale for switching to a DLL is to permit updates to take place to the DLL's through Windows Update, and presumably close any security holes. My own experience has been the occasional, albeit rare time when the update is buggy and a perfectly solid application suddenly blows up. (Yes that was 10 years ago, but the bitter taste lingers). Personally, I recommend static linking which is impervious to this problem.

A more recent episode:

"BUG: Black Patchday for all OS from XP and later 3. - MFC 8.0 (VC-2005) or MFC 9.0 (VC-2008) linked dynamically to the MFC may not find the MFC language DLLs after installation of the security packs dated April 12th 2011"

http://bit.ly/hbDHt3

Giovanni

Answer 5

On 06/03/2012 21:17, Brian Muth [MVP] wrote:

"BUG: Black Patchday for all OS from XP and later 3. - MFC 8.0 (VC-2005) or MFC 9.0 (VC-2008) linked dynamically to the MFC may not find the MFC language DLLs after installation of the security packs dated April 12th 2011"

http://bit.ly/hbDHt3

Giovanni

I realize this may cause problems but I have no choice (as stated above) since I will need /clr compilation.