Visual C++ Libraries DLL Deployment

There have been lots of questions and concerns about deploying VC++ 2005 applications and what are the possible ways of deploying the VC++ Libraries.

Thanks to Sridhar Madhugiri on the VC++ Libraries team, here is a quick dump that can help in the deployment process.

Following discusses the deployment options available to deploy VC Libraries DLLs with a product. Online docs will be updated to incorporate this information.

 

Most of the information below is documented but spread across various topics.

 

General information: https://msdn2.microsoft.com/ms235316(en-US,VS.80).aspx Talks about some of the pros/cons of the options.

Servicing Concerns :

Irrespective of which option you use, any serious security issue will be deployed through Microsoft Update as a security update. You don’t have to release a patch to your product to deploy the fixed VC Libs DLLs.

Deployment Options :

1. Install to Winsxs Directory using MSMs merged into app setup.

2. Private Assembly install under app directory.

3. Install to Winsxs Directory using vcredist*.exe.

1. Install to Winsxs Directory using MSMs merged into app setup.

Merge Modules that install the DLLs to WinSXS can be found under Program Files\Common Files\Merge Modules. These MSMs can be merged into the app setup. Various Setup authoring tools are available and allow merging MSMs. Please refer to the Authoring tool documentation to determine how to merge the MSMs. Merge the required MSMs into the app setup.

Pros : Only deploy the assemblies that the app depends on.

Cons : App has to have its own setup, requires admin rights to install

ATL

X86 - Microsoft_VC80_ATL_x86.msm, policy_8_0_Microsoft_VC80_ATL_x86.msm

IA64 - Microsoft_VC80_ATL_x86_ia64.msm, policy_8_0_Microsoft_VC80_ATL_x86_ia64.msm

X64 - Microsoft_VC80_ATL_x86_x64.msm,policy_8_0_Microsoft_VC80_ATL_x86_x64.msm

CRT

X86 - Microsoft_VC80_CRT_x86.msm, policy_8_0_Microsoft_VC80_CRT_x86.msm

IA64 - Microsoft_VC80_CRT_x86_ia64.msm, policy_8_0_Microsoft_VC80_CRT_x86_ia64.msm

X64 - Microsoft_VC80_CRT_x86_x64.msm, policy_8_0_Microsoft_VC80_CRT_x86_x64.msm

MFC

X86 - Microsoft_VC80_MFC_x86.msm, policy_8_0_Microsoft_VC80_MFC_x86.msm

IA64 - Microsoft_VC80_MFC_x86_ia64.msm, policy_8_0_Microsoft_VC80_MFC_x86_ia64.msm

X64 - Microsoft_VC80_MFC_x86_x64.msm, policy_8_0_Microsoft_VC80_MFC_x86_x64.msm

OpenMP

X86 - Microsoft_VC80_OpenMP_x86.msm, policy_8_0_Microsoft_VC80_OpenMP_x86.msm

IA64 - Microsoft_VC80_OpenMP_x86_ia64.msm, policy_8_0_Microsoft_VC80_OpenMP_x86_ia64.msm

X64 - Microsoft_VC80_OpenMP_x86_x64.msm, policy_8_0_Microsoft_VC80_OpenMP_x86_x64.msm

MFCLOC

X86 - Microsoft_VC80_MFCLOC_x86.msm, policy_8_0_Microsoft_VC80_MFCLOC_x86.msm

IA64 - Microsoft_VC80_MFCLOC_x86_ia64.msm, policy_8_0_Microsoft_VC80_MFCLOC_x86_ia64.msm

X64 - Microsoft_VC80_MFCLOC_x86_x64.msm, policy_8_0_Microsoft_VC80_MFCLOC_x86_x64.msm

Debug DLLs cannot be redistributed. They are shipped with VC for debugging purposes. See Online VC Documentation for details

DebugCRT

X86 - Microsoft_VC80_DebugCRT_x86.msm, policy_8_0_Microsoft_VC80_DebugCRT_x86.msm

IA64 - Microsoft_VC80_DebugCRT_x86_ia64.msm, policy_8_0_Microsoft_VC80_DebugCRT_x86_ia64.msm

X64 - Microsoft_VC80_DebugCRT_x86_x64.msm, policy_8_0_Microsoft_VC80_DebugCRT_x86_x64.msm

DebugMFC

X86 - Microsoft_VC80_DebugMFC_x86.msm, policy_8_0_Microsoft_VC80_DebugMFC_x86.msm

IA64 - Microsoft_VC80_DebugMFC_x86_ia64.msm, policy_8_0_Microsoft_VC80_DebugMFC_x86_ia64.msm

X64 - Microsoft_VC80_DebugMFC_x86_x64.msm, policy_8_0_Microsoft_VC80_DebugMFC_x86_x64.msm

DebugOpenMP

X86 - Microsoft_VC80_DebugOpenMP_x86.msm, policy_8_0_Microsoft_VC80_DebugOpenMP_x86.msm

IA64 - Microsoft_VC80_DebugOpenMP_x86_ia64.msm, policy_8_0_Microsoft_VC80_DebugOpenMP_x86_ia64.msm

X64 - Microsoft_VC80_DebugOpenMP_x86_x64.msm, policy_8_0_Microsoft_VC80_DebugOpenMP_x86_x64.msm

https://msdn2.microsoft.com/ms235290(en-US,VS.80).aspx

2. Private Assembly install under app directory.

The VC Libs files can be installed under the app directory as a private assembly. The files required for the private assembly are under <VS install path>\vc\redist. Copy the required sub directories to the app directory.

Pros : App does not have a setup, xcopy deploy, Non admin install, Select the assemblies that the app uses, run from share

Cons : Not suitable when a product installs multiple binaries and these are installed in various directories (assembly has to be duplicated under each directory)

https://msdn2.microsoft.com/ms235291(en-US,VS.80).aspx

3. Install to Winsxs Directory using vcredist*.exe.

vcredist*.exe found under <VS install path>\sdk. These are standalone exe that installs all the VC libs to WinSXS directory. It installs only the retail versions of the DLLs.

https://msdn2.microsoft.com/ms235291(en-US,VS.80).aspx

Pros : App does not require a Setup, Has to be installed on the machine once and multiple apps can use the central version.

Cons : Installs all the VC Libs DLLs irrespective of whether they are used by the app, requires admin rights to install

Thanks,

Ayman Shoukry

Program Manager

VC++ Team

Comments

• Anonymous
  April 04, 2006
  "requires admin rights to install" is indeed a big problem... and makes third option the only one for programs.
  
  Can't we call a winxp service like "xp update" with some magic parameters to make it update automatically to those requirement  (or "here is a windows update link")
  
  Best would be Xp already auto-install those requirements on every computer, so that only dev needs would be to annonce "your xp need to be updated..."

• Anonymous
  April 05, 2006
  As you probably know, the update is owned by the OS team. Nevertheless, I would highly encourage you to log your suggestion at http://lab.msdn.microsoft.com/productfeedback/default.aspx.
  
  Thanks,
  Ayman Shoukry

• Anonymous
  April 12, 2006
  What is the best way to determine if the run-time files are available already on the target machine? This would allow an intelligent setup program to tell the user to get and install vcredist*.exe or to automatically retrieve that if the user is online. Setup files would be kept small but still ensure full operation everywhere.
  
  It is simply inefficient to think that tons of application setups will have to carry the runtime files when they are only needed once per target machine.

• Anonymous
  May 11, 2006
  I tried many methods but still i am not able to deploy my vc++ 2005 application. I installe IE6, then installed windows installer 3.1 redist, after that I installed vcredist_x86.exe. After doing all these my application is still not running. Then I manually copied CRT, MFC and ATL dlls along with manifest in the application folder.
  And, my application still fails to start on other machine.
  Please help me.
  javed.h@gmail.com

• Anonymous
  May 12, 2006
  Could you raise the issue on the VC++ forums (http://forums.microsoft.com/MSDN/default.aspx?forumgroupid=8&siteid=1) so that myself and others can help. We will probably need more details though.
  
  Thanks,
  Ayman Shoukry

• Anonymous
  June 11, 2006
  The comment has been removed

• Anonymous
  July 21, 2006
  Does a dll compiled on win 2000 can give problems while using those dlls on win 2003 server?

• Anonymous
  August 01, 2006
  This is realy anoying, the compiler should automatically add the files needed to run your applications you create on other machines or atleast provide updates on http://windowsupdate.microsoft.com/
  It's my guess that they forgot about this problem and was too eager to get MS VS 2005 released. Most programmers want to get on creating their applications and continue learning with their desired language and not have to be dealing with work-arounds for something that should work anyway. MS VS 2003 was better by far, just my opinion.
  thanks

• Anonymous
  August 11, 2006
  The comment has been removed

• Anonymous
  December 10, 2006
  This is ridiculously complicated.I have wasted THREE days of development time trying to get our software to install on Vista RTM.  I have followed all the advice and have made no progress.My installer package contains the merge modules for the latest MSVCRT80 and ATL80.  This merge modules FAIL TO INSTALL on Vista.They install just fine on XP Pro - both 32- and 64-bit.I never had this trouble with Visual Studio .NET 2003.  Only since porting to .NET 2005.And now, out-of-the-blue, the installer package has somehow decided that .NET Framework 2.0 is needed - it's all unmanaged code.

• Anonymous
  January 13, 2007
  You don't appear to have updated the merge modules for SP1 only the vcredist*.exe

• Anonymous
  January 29, 2007
  Can you explain me why this happens and how to resolve it?I posted my question here.http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1158230&SiteID=1Thank you.P.S. Delay loading didn't help. At the point when it loads a dll, it displays the error message.

• Anonymous
  February 15, 2007
  PingBack from http://jlinx.de/blog/?p=265

• Anonymous
  February 23, 2007
  A very simple C++ program compiled under VC 2005 failed to deploy on my Windows 2003 server.  Got the following error while installing the vcredist_x86.exe:Error 1723:  There is a problem with this Windows Installer package.  A DLL required for this install to complete could not be run.  Contact your support personnel or package vendor.Any idea how to resolve this?Jeff

• Anonymous
  February 23, 2007
  I found it.  I ended up have to install the latest copy of Windows Installer 3.1 prior to installing the VCRedist_x86.exe.JML

• Anonymous
  April 05, 2007
  I there sp1 release for the c++ redit libraries??

• Anonymous
  April 06, 2007
  I found that that even with all of the latest Visual Studio 2005 updates in place.  The redistributable vcredist_x86 located in C:Program FilesMicrosoft.NETSDKv2.0BootstrapperPackagesvcredist_x86.exe is dated 12/2/2006 and installs what appears to be the latest version of the DLLs.  But the Microsoft_VC80_CRT_x86.msm and Microsoft_VC80_MFC_x86.msm located in C:Program FilesCommon FilesMerge Modules are dated as 5/16/2006 whic are installing Beta verrsions of the DLLs.  THe X64 versions of these MSMs are dated 12/2/2006 so I assume that either something went wrong with an update or the non x64 versions were left out of an update.Are there updated MSMs available and how do I get them?

• Anonymous
  April 09, 2007
  Wait, wait, wait... Let me get this straight.I have to install all these DLL's and the redist-package on EVERY single machine i want to run my application on?Is this the death of VC++ or did i misunderstand?

• Anonymous
  April 09, 2007
  Wait, wait, wait... Let me get this straight.I have to install all these DLL's and the redist-package on EVERY single machine i want to run my application on?Is this the death of VC++ or did i misunderstand?

• Anonymous
  April 22, 2007
  how should i call a third party dll in an MFC application.please send me steps for it.

• Anonymous
  May 03, 2007
  With VS SP1,  most of manifest files have been updated but,C:Program FilesMicrosoft Visual Studio 8VCredistx86Microsoft.VC80.ATLMicrosoft.VC80.ATL.manifestis still old (dated 9/23/2005)it still hasversion="8.0.50608.0"

• Anonymous
  May 08, 2007
  whats the basic difference between win32 dll and COM dll?

• Anonymous
  June 03, 2007
  Where do I find a MSM for ActiveSync so that my VS 2005 installer will install ActiveSync for my application that Ihave developed using VS 2005?Stewart

• Anonymous
  September 21, 2007
  Is there any way to statically link to CRT library so that applications can run on end user's XP without do any thing extra?If not, and you need to install/copy something before you can run your apps created VS 2005,  I would say that VS 2005 does not support XP or XP does not support VS 2005; and if you want your apps to run on XPs, then don't use VS 2005.

• Anonymous
  October 02, 2007
  I just static link to everything. ATL also if I'm making a COM server.Use WTL instead of MFC (MFC is sort of legacy these days). Guys, lets move forward here - not backward.

• Anonymous
  October 11, 2007
  I'm sticking with VS2003. You guys have completely, UTTERLY messed this up.Simplify. Simplify. Simplify the deployment process!

• Anonymous
  October 12, 2007
  The comment has been removed

• Anonymous
  October 14, 2007
  This is a total mess. The Visual Studio project generates errors and installs every stupid DLL for each merge module, not just the latest one I'm compiling against. Instead of a 600K install, I have a 5MB install.Unfortunately, nothing will be done like always. Can't you people do anything right?

• Anonymous
  November 23, 2007
  http://z500a.com/replica-watches/breitling-bentley-replica-watch.php

• Anonymous
  December 04, 2007
  I've found that the redistribution installer returns instantly and the installation proceeds in the background.While this is cute (the author probably thought he was a great coder, using external processes & all), this is a nightmare for 3rd party trying to include this installer within their own installer. You can not easily know when the install actually completes. You can run into issues when you try to install other things afterwards (with errors from the installer, because other installs are still running), or, in my case, you can't have a script install this then move on & restart the machine as the installer might still be working (thanks to XP Embedded & it's broken shutdown process that doesn't close all processes cleanly...)Now, how can make this installer be a team player and only "exit" when it is really done?thanks!

• Anonymous
  February 13, 2008
  I have only just started a project with VS 2008!Should I abandon my effort right now given what I have been seeing here? I have been developing it on a Vista machine and would like the exe to work on XP too!Am I insane to try this?

• Anonymous
  February 14, 2008
  Can somebody tell me when do we get the following error:Program 'file_name.dll' failed to load. Error 14001please reply soon...Thanks in advance

• Anonymous
  March 13, 2008
  i'm also experiencing the same problem as all the people have.Error: The Side-by-side configuration information.......(14001)Warning: Atleast one module has an unresolved import due to a missing export function.....i tried to install the vcredist.exe but nothing happens.i copied all necessary dlls to their respective directories but still nothing happens. i tried to change the Embed Manifest from its default which is Yes to No but it gave me another error. can someone help me with my issue?

• Anonymous
  May 05, 2008
  PingBack from http://blog.kalmbach-software.de/2008/05/05/main-disadvantage-of-really-applocal-deployment/

• Anonymous
  May 23, 2008
  Could somebody from Microsoft please clarify this?With the manifest embedded inside the .exe file, an isolated assembly works on XP but not on Windows 2003.By isolated I mean a folder structure like this:MyFolder

  MyApp.exeMicrosoft.VC80.MFC    <manifest file>    <mfc dll>

• Anonymous
  June 28, 2008
  How can i load differernt DLL with same name in single executable, plz relpy me.

• Anonymous
  July 21, 2008
  Hi,I'm creating a setup that will install the following:.NET 2.0 SP1CRT (C Runtime Library) An ActiveX. I have 2 questions:How do I know that CRT was already installed ? Can I install CRT in "silent mode" ?

• Anonymous
  August 03, 2008
  To run your vc++ 2005-08 applications on another machine do as following:1- select a project from solution explorer2- choose "Propertise" from "Project" menu;3- expand "C/C++" node and select "Code Generation" from left pane4- change "Runtime Library" to "Multi-threaded DLL (/MD)" from right pane.you must do all of these steps for any project exist in your solution and at the end rebuild your soultion using "Build" menu.the next thing you need to run your apps on another machine is that the target machine must have .Net Framework installed with the same version of your apps.you can find your targeted framework version by doing the steps 1 and 2 and then:3- expand "Common Propertise" and select "Framework and Refrences" from left pane.4- In the right pane you can find your targeted frame work from a combobox and you can change it.Sorry for my bad english

• Anonymous
  September 22, 2008
  I wasted a lot of time in the last day with our installer, which I managed to track down to the fact that VS2008 SP1 links against the RTM CRT & MFCs unless you use the _BIND_TO_CURRENT_VCLIBS_VERSION macro.  One of the many problems with this, is that when you install VS 2008 SP1, it replaces the MSM files with the new version of the CRT/MFC/ATL dlls.Am I missing something, or does this mean VS 2008 SP1 in it's shipped configuration creating unworkable installers?I'm now trying to decide if I should manually roll back the MSM files, or if I should update all 100 of our projects to include the _BIND_TO_CURRENT_VCLIBS_VERSION macro.How have others delt with this?  I'm new to all this SxS & manifest stuff, so please excuse me if I have missed something obvious.

• Anonymous
  October 06, 2008
  Hello, I see a lot of questions, no answers. Hopefully someone will be able to answer my question. VS 2008 RTM, I am including the all the MSM (atl,crt,mfc,openMP) in my installation, works great in XP, but on VISTA, I get erros at the end of the installation wehn registering the dlls: cannot lod file. I let the installation finish, try to manually register the dlls: it works!!If I run vcredist.exe before hand, everything works fine.Is there anyhting that vcredist.exe does, that the msm do not do?Thanks in AdvanceAntonioantonio dot pellizzaro at autodesk

• Anonymous
  October 15, 2008
  In my application I have Used some microsoft VC++ dll's also along with .net dll's.Now Iam getting "RUNTime Error" pop-up screen message as below" The Application has been terminated in an Unusual Way"On googling i came to know that some dll's like msvcrt.dll of windows server 2003 has to be changed...But Iam not pretty sure about it..In Production/test environment there is only framework installed ,but there is no visual studio installed on it.may be due that this error may occur...So kindly post your suggestions and views to help meI tried to resolve by following ways but failed to achieve otI have installled the redistributable package suggested by you.after installing i restarted the PC even now also I got the same runtime pop-up error.Then I checked even with the dependency walker for the dll.I found that there is no miising dll.Then I tried by installing Visual C++ express edition..even then also i got the same pop-up error.Kindly help me.....

• Anonymous
  October 21, 2008
  The comment has been removed

• Anonymous
  October 30, 2008
  I chose the second way to deploy my app : 2. Private Assembly install under app directory.But even with my VS redist Microsoft.VC80.CRT folder copied in the same directory as my app (on a computer without visual), it doesn't workI'm sure thousands of people already had the same problem, could you help me please i already spent too much time to try making this work !!

• Anonymous
  November 20, 2008
  The comment has been removed

• Anonymous
  January 17, 2009
  PingBack from http://www.hilpers.com/1060817-mfcnext-installiert-in-manifesten-steht

• Anonymous
  January 21, 2009
  PingBack from http://www.keyongtech.com/737028-application-configuration-error-c-vs2005

• Anonymous
  June 16, 2009
  PingBack from http://topalternativedating.info/story.php?id=15763

• Anonymous
  June 19, 2009
  PingBack from http://debtsolutionsnow.info/story.php?id=12838

• Anonymous
  July 27, 2009
  I am facing same issue where in my ocx file needs two dll MFC90.dll and MSVCR90.dll. Both are in different folder and when i ran dependency walker it is not able to find each other.Please help me out here.

• Anonymous
  January 30, 2010
  E-MAIL:JULESSCHAFFTER@HOTMAIL.COM

• Anonymous
  April 09, 2010
  I tried using the Merge Module approach.  This seemed to work okay when installing the application at first, but when I released an update to my application, the installer for the update version would hang for several minutes.  I figured out that it was trying to uninstall the Merge Module from the previous version, and this was taking a very long time.  So then I decided to go with the vcredist approach, so at least the installer would not have to uninstall and reinstall the runtime libraries every time I release an update to my application.  But now it's a pain because any time a new user installs the application they have to install the vcredist first.  It seems like there should be a better way.