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:,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



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



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



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



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



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



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



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



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,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),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.,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



  Ayman Shoukry

  Program Manager

  VC++ Team

Comments (51)
  1. Tuan Kuranes says:

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

  2. AymanS says:

    As you probably know, the update is owned by the OS team. Nevertheless, I would highly encourage you to log your suggestion at


    Ayman Shoukry

  3. Olaf Zander says:

    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.

  4. Javed says:

    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.

  5. AymanS says:

    Could you raise the issue on the VC++ forums ( so that myself and others can help. We will probably need more details though.


    Ayman Shoukry

  6. logisimo says:

    DLL Deployment could reach transparancy when enough data on the handle to the process is known, as well as what DLL’s are loaded and unloaded. When the client makes a procedure call remotely, the server will dispatch that routine to perform the service and reply. If the machine is a different version, model, yet can be piped without defining network interface, the process context switch involves extracting the adress from the kernel environment protection block into the cr3 register. Each remote installtion by registering the DLL or remote procdure call, it involves a routing mechanism through which the request will be processed. If Windows Server 2003 updates both the local and the target, then ( I think, I’m not sure) the DLL, if not installed where DLL’s are grouped on the target, could link to the procedure that used that DLL. Or the process on the remote culd be hooked and the DLL injected during the API hook. Normally,  all, except for one of the entry points into the DLL but  one are virtual functions. The dereferenced or indirect function call by the virtual function table holding the funcion that contains the function pointer prevents the caller to link against their symbolic names during the design phase. The keyword extern could be used to prevent symbolic differences by a global function that bootstraps the caller client Esentially, when out of the DLL heat, two systems could expect the import library from the DLL to export the same symbol. Therefore, deplying the DLL on a target machine. A module has both a public and private parts to keep details of implentation hidden and consequently avoid the linear level and use indirection, as if it were a hash search. The local machin thus has a runtime extended functionlity by objet interrogation. The output of these COM standard inputs is the DLL cazn decouple itself from the local C++ compiling. The Distributed Computing Environment (DCE) uses the IDL  compiler to Microsoft’s Remote Procedure Call is designed for that very situation. Component access over transports ( without the network interface defining the pipe) and machine boundaries. This is evidentally due to reiturating the binary standard, and in pert to avoid the detail of the network interface. One may find a parallel in the PRC runtime library to fund a process and map to an endpoint as if it were a protocol defintion. The endpoints are in phase and on the same terms. Makes sure that contractual agreement is "binding".  

  7. dts says:

    Does a dll compiled on win 2000 can give problems while using those dlls on win 2003 server?

  8. deen says:

    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

    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.


  9. Jim Howard says:

    I’m trapped in some kind of dll hell since I’ve started trying to move my apps to VC8.  

    I get random crashes on startup of several of my mfc apps with the message "The application failed to initialize properly (0xc0000034)".  This crash happens as soon as kernel32.dll loads, long before the debugger becomes useful.

  10. John Miller says:

    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.

  11. MCFH says:

    You don’t appear to have updated the merge modules for SP1 only the vcredist*.exe

  12. JongAm Park says:

    Can you explain me why this happens and how to resolve it?

    I posted my question here.

    Thank you.

    P.S. Delay loading didn’t help. At the point when it loads a dll, it displays the error message.

  13. Jeff Lynn says:

    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?


  14. Jeff says:

    I found it.  I ended up have to install the latest copy of Windows Installer 3.1 prior to installing the VCRedist_x86.exe.


  15. marcos says:

    I there sp1 release for the c++ redit libraries??

  16. William A. Miller II says:

    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?

  17. Anton Balzer says:

    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?

  18. Anton Balzer says:

    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?

  19. chandra says:

    how should i call a third party dll in an MFC application.please send me steps for it.

  20. Murali Tummala says:

    With VS SP1,  most of manifest files have been updated but,

    C:Program FilesMicrosoft Visual Studio 8VCredistx86Microsoft.VC80.ATLMicrosoft.VC80.ATL.manifest

    is still old (dated 9/23/2005)it still has


  21. Thalha says:

    whats the basic difference between win32 dll and COM dll?

  22. Stewart Clark says:

    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?


  23. Domican Terce says:

    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.

  24. Kernel Mutex says:

    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.

  25. No thanks says:

    I’m sticking with VS2003. You guys have completely, UTTERLY messed this up.

    Simplify. Simplify. Simplify the deployment process!

  26. Kernel Mutex says:

    Good idea No thanks. Sticking with version 7.1 of the runtimes will give you more robust apps. I found the VC 8.0 runtimes somewhat buggy. Especially when calling COM interfaces from Win32 apps. First Chance Exceptions were getting out of step with CoUninit… 15 minutes after my app was closed – up would pop a message saying the runtime terminated in a queer way!! How could I ship that to paying customers?!?! 😐

  27. Joe says:

    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?

  28. Georges says:

    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?


  29. David says:

    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?

  30. Aviral says:

    Can somebody tell me when do we get the following error:

    Program ‘file_name.dll’ failed to load. Error 14001

    please reply soon…

    Thanks in advance

  31. Toni says:

    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


    • 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?

  32. GerOD says:

    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:


        &lt;manifest file&gt;
        &lt;mfc dll&gt;
  33. vbsecure says:

    How can i load differernt DLL with same name in single executable, plz relpy me.

  34. Dani Peer says:


    I’m creating a setup that will install the following:

    1. .NET 2.0 SP1
    2. CRT (C Runtime Library)

    3. An ActiveX.

    I have 2 questions:

    1. How do I know that CRT was already installed ?

    2. Can I install CRT in "silent mode" ?

  35. To run your vc++ 2005-08 applications on another machine do as following:

    1- select a project from solution explorer

    2- choose "Propertise" from "Project" menu;

    3- expand "C/C++" node and select "Code Generation" from left pane

    4- 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

  36. Phil Anderson says:

    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.

  37. Antonio Pellizzaro says:

    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 Advance


    antonio dot pellizzaro at autodesk

  38. sumanknm says:

    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 me

    I tried to resolve by following ways but failed to achieve ot

    1. I 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.

    1. Then I checked even with the dependency walker for the dll.

    I found that there is no miising dll.

    1. Then I tried by installing Visual C++ express edition..even then also i got the same pop-up error.

    Kindly help me…..

  39. rbroadbridge says:

    This is probably simple for you chaps.

    I have a VC++ program which requires the MFC and CRT dlls to run.

    I compile the program using cl/clr.

    I generate signed application and deployment manifests using mage.

    I am trying to deploy it using ClickOnce.

    I have used ClickOnce successfully in a previous version of my program which didn’t need the MFC components.

    My ClickOnce install fails on a clean target with an error (eg) "Cannot copy mfc90.dll – file already exists"

    I believe it’s because it (a) reads the microsoft.vc90.mfc manifest, and then installs the dlls’ referenced in this manifest; and then (b) tries to

    copy the dll’s again because they are seperately defined in the ClickOnce application manifest.

    If I don’t include the MFC dll’s (eg mfc90.dll) in the distribution folder, then the install fails because it can’t find the required components of


    And if I do include the dll’s it tries to copy them twice and fails!

    All help appreciated…

  40. thomasp says:

    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 work

    I’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 !!

  41. cbuck says:

    With Borland’s products, when you start the application it will inform you that it cannot find a required DLL and will even give you the name of the DLL file it could not find. So you go out, find the file, copy it to the application directory, and try again. After several iterations of this you have all of the necessary run-time libraries installed and the application runs.

    With VC Express, however, when you try to run your application you get the helpful message: "The system cannot execute the specified program." Then you spend the next several days trying to track down real source of the problem. Is it missing DLLs? Different versions of DLLs? A manifest problem? Some combination? None of the above?

    COME ON GUYS! YOU NEED TO FIGURE THIS OUT! Write a tech sheet with step-by-step instructions how to deploy an application. Seriously, why can’t the IDE create a deployment folder with everything the application needs to run? THIS SHOULD NOT BE THIS DIFFICULT! Everyone needs to deploy their apps to a PC without the IDE installed. You need to make this easy.

    My question: What do I need to do to make my simple console program work on a computer without installing VS?

  42. haresh says:

    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.


  44. Nathan says:

    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.

Comments are closed.

Skip to main content