Howto: Deploy VC2008 apps without installing vcredist_x86.exe

There are several reasons for xcopy deployment of an application (also known as application local). One main reason is that you are independent of what the target computer has installed.
Also your application always uses the “correct” (or better: tested) version of DLLs, regardless of what MS installed or updated (see: .NET2 SP1 update breaks old apps!?).

The easiest way to overcome the problem is to link static against the CRT/MFC. But in some scenarios this is not an option and not possible.

But to be independent from OS updates or from vcredist_x86.exe installations of other apps, you need to do the following steps:

  • Remove the auto-generation of manifests (from all DLLs) and change the manifest generation form your EXE to an external manifest; you can do this by choosing: Project|Properties|Configuration Properties|Manifest Tool|Input and Output|Embed Manifest: No
  • Recompile your application and modify the external manifest as follows:
  • Copy your application and the external manifest to your deployment directory
  • Open the manifest-file (appname.exe.manifest) and remove the “publicKeyToken” from all MFC/CRT/ATL/OpenMP entries. Please leave the publicKeyToken to the “Microsoft.Windows.Common-Controls” entry.
  • Copy all neccessary directories under %ProgramFiles%\Microsoft Visual Studio 9.0\VC\redist\x86 to your deployment directory
  • In all sub-directories (Microsoft.VC90.CRT, optional: Microsoft.VC90.MFC, Microsoft.VC90.ATL, Microsoft.VC90.OPENMP, Microsoft.VC90.MFCLOC) open the manifest-file and also remove the publicKeyToken
  • Also lookup the version info from these manifest files and correct the version-info of the corresponding entries in your application manifest file
  • Save all manifests and let your program run; it should now run on all supported OS without installing anything…

After doing all these manifest stuff you can also embed the manifest into your application (EXE). And of course: The same can be done with x64 and IA64 apps.

I have made an example of the default MFC app (4.6 MB) for reference.

The (simple) manifests for the new MFC feature pack and the application looks like:

Application.exe.manifest



  
    
      
        
      
    
  
  
    
      
    
  
  
    
      
    
  
  
    
      
    
  

Microsoft.VC90.CRT.manifest



    
    
     
     
    

Microsoft.VC90.MFC.manifest



    
    
     
     
     
    

Instead of putting the “Microsoft.VC90.MFC” and “Microsoft.VC90.CRT” directories into the application folder, you can also just put the files from these folders into the application directory. The main advantage is, that your app will also work on W2k-SP4.

Here is also my older post for VS2005.

36 thoughts on “Howto: Deploy VC2008 apps without installing vcredist_x86.exe

  1. Koro

    Ah, these manifests sure are a pain, aren’t they?

    I for one miss the simpler times of MSVCRT.dll: it came with the OS, therefore nothing needed to be distributed.

    Other solutions I’ve developed over time:
    – Compile with the .h files from VS6 and link with the .lib files from VS6 when doing the release build
    – Patch the check_manifest function in the appropriate DLLs with “b8 01 00 00 00 c3” a.k.a. “return true” 🙂

  2. Koro

    Yeah, I read that post a while ago, don’t worry.

    But even if MSVCRT is not *officially* shipped with the OS, it still comes with it since Win95c if I remember well, and it’s still updated with more recent functions to match the feature set of VS’s MSVCRx0.dll, so, from a practical point of view, if one does not use too much C++ stuff, it ships with the OS 🙂

    There’s also a mini-CRT in NTDLL.dll, containing just the minimum (string functions and exception handling stuff), I might use it someday too…

  3. Pingback: Jochen Kalmbach’s Blog » Blog Archive » Main disadvantage of (really) AppLocal deployment

  4. Eric

    I’m swimming in plain manifest hell and I got a question :

    I have to work with a .dll I’ve been provided (so I cannot change anything from this .dll), that have got the following manifest :

    I compile my plain C/C++ application with VS2005. The following manifest is auto generated for my application :

    Since I don’t want to rely on a windows installation to deploy this app. I’d like to build this assemblies as local. However I don’t know how to handle the 2 versions of the CRT specified in the .dll manifest (that I cannot control).

    Is it only possible ?

  5. Eric

    The extract of the manifest files didn’t appear in the above post…

    Here in shorter version :
    the .dll
    assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” version=”8.0.50727.762″
    assemblyIdentity type=”win32″ name=”Microsoft.VC80.MFC” version=”8.0.50727.762″
    assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” version=”8.0.50608.0″
    my app
    assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” version=”8.0.50608.0″

  6. John

    What you have provided works. I am able to compile my application on an XP machine and run it without a problem from a thumb drive on a Vista machine.

    An additional question, you state:
    “After doing all these manifest stuff you can also embed the manifest into your application (EXE).”

    Are you saying that I can embed the “fixed” manifest into my application? If so, how do I do that? When I rebuild the application, it generates a new manifest with the old settings. How do I get it to embed a manifest file that I modified?

    Thanks

  7. Ray Broadbridge

    This is probably trivial to you chaps, but grateful for any help:
    I have been using mageui to build manifests to deploy a program using ClickOnce. The program’s manifest (generated using cl/clr) refers to dependent assemblies microsoft.vc90.mfc and microsoft.vc90.crt.
    If I don’t put msvcp90.dll, msvcr90.dll … mfcm90u.dll etc in the distribution folder, the install fails because it can’t find them.
    If I add them to the distribution directory but don’t re-run mage to add them to the manifest, the install finds them but then objects that
    “The + Manifest XML signature is not valid.
    + No signature was present in the subject.”
    If I add them to the distribution directory and re-run mage, including them in the distribution, the install fails because it says “The file \\…\\…msvcr90.dll (etc) already exists”.
    This presumably is because it’s trying to install the dll’s once because it knows they are part of the microsoft.vc90.crt / mfc assembly, and once again because they’re in the list for deployment.
    Is there a way round this ?

  8. Pingback: VC Runtimes 2005/2008 vs. alte Projekte | hilpers

  9. Pingback: "Application has failed to start..." error message with VS2005 on new machine | keyongtech

  10. IMMI

    Hi Jochen,
    Thanks for your instant reply.

    Yes, i have read about PublicKeyToken entry from MSDN forums. First of all, you have mentioned about “Application Manifest” file but the problem here is that i have been provided with an already deployed application and it may have its manifest file embedded in it as its not visible to me. Also, I cannot change its implementation. So, any thing on the development side is out of question.

    Now, coming towards removal of PublicKeyToken from DLL files, i have tried to remove this entry from the manifests files but it didnot work. Is there any issue of policy files? As you have not say much about policy files. I have following set of files for a particular assembly say CRT:

    3 DLL files (msvcr80.dll, msvcp80.dll, msvcm80.dll)
    1 manifest file
    1 catalogue file for manifest
    1 policy file
    1 catalogue file for policy

    Now, tell me is there any need of the Policy files? If YES, then how can i make them work LOCAL with given structure OR i have to use some other ways in addition to the removal of PublicKeyToken.

    Thanx.

  11. jkalmbach Post author

    Policy files are only used, you you *have* specified a publicKeyToken. So if you have removed the publicKeyToken from *all* manifest files, you have no conflicts with policies.

    But you must remove the publicKeyToken from the DLL-manifests and from your EXE-manifest!!!

  12. IMMI

    Hi jKalmbach,

    Hp ur Fine and thnx for showing interest.

    OK! i have removed the publicKeyToken entry from all of my DLL-manifests. However, as i have stated earlier that the application i m working on is provided to me for release and i cannot do anything for development. It has its EXE-manifest embedded in it as there is no external manifest file found.

    Also, I have used a manifest extractor software “Resource Tuner” through which i have found an embedded manifest listed referring to the assemblies (CRT, MFC, Common-Controls). I have tried to make an application manifest myself just like the embedded one but It didnot work.

    Is there any way to enforce application to use an external manifest instead of an embedded manifest file? or Is there any role Application Configuration File?

    Thanx in advance.

  13. jkalmbach Post author

    Nom you cannot enforce external manifests (only in XP, but not in Vista). Therefore you need to modify the embedded manifest. But this should work….
    But if you are not the developer of this application, you should contact the developer!

  14. IMMI

    Hi Jochen,

    Hp ur fine…

    Yeah i have tried it so but the problem is still there. Infact i have done some workaround with Application Manifest as well as Application Configuration Files but all in vain as application is still not running.

    I m sending you a snippet of Application Manifest file that i have done. It may help you guide me more precisely…

    Application.exe.manifest

    Application.exe.config

    Thnx in advance…

  15. IMMI

    assembly xmlns=”urn:schemas-microsoft-com:asm.v1″
    manifestVersion=”1.0″

  16. IMMI

    Hi Jochen, Sorry! i have been trying to add code alongwith the tag symbols but unable to add. So, putting (tag) instead of each angle bracket… Hp u understand 🙁

    Application.exe.manifest
    ——————————

    (tag)assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestVersion=”1.0″(tag)
    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.ATL” version=”8.0.50727.762″ processorArchitecture=”x86″ (tag)(tag)/assemblyIdentity(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” version=”8.0.50727.762″ processorArchitecture=”x86″ (tag)(tag)/assemblyIdentity(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.MFC” version=”8.0.50727.762″ processorArchitecture=”x86″ (tag)(tag)/assemblyIdentity(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.MFCLOC” version=”8.0.50727.762″ processorArchitecture=”x86″ (tag)(tag)/assemblyIdentity(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)
    (tag)/assembly(tag)

    ——————————————————————————

    Application.exe.config
    ————————-

    (tag)configuration(tag)
    (tag)runtime(tag)
    (tag)assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″(tag)
    (tag)publisherPolicy apply=”no”/(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.ATL” version=”8.0.50727.762″ processorArchitecture=”x86″/(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)bindingRedirect oldVersion=”8.0.41204.256-8.0.50608.0″ newVersion=”8.0.50727.762″/(tag)
    (tag)bindingRedirect oldVersion=”8.0.50727.42-8.0.50727.762″ newVersion=”8.0.50727.762″/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” version=”8.0.50727.762″ processorArchitecture=”x86″/(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)bindingRedirect oldVersion=”8.0.41204.256-8.0.50608.0″ newVersion=”8.0.50727.762″/(tag)
    (tag)bindingRedirect oldVersion=”8.0.50727.42-8.0.50727.762″ newVersion=”8.0.50727.762″/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.MFC” version=”8.0.50727.762″ processorArchitecture=”x86″/(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)bindingRedirect oldVersion=”8.0.41204.256-8.0.50608.0″ newVersion=”8.0.50727.762″/(tag)
    (tag)bindingRedirect oldVersion=”8.0.50727.42-8.0.50727.762″ newVersion=”8.0.50727.762″/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)dependency(tag)
    (tag)dependentAssembly(tag)
    (tag)assemblyIdentity type=”win32″ name=”Microsoft.VC80.MFCLOC” version=”8.0.50727.762″ processorArchitecture=”x86″/(tag)
    (tag)publisherPolicy apply=”no”/(tag)
    (tag)bindingRedirect oldVersion=”8.0.41204.256-8.0.50608.0″ newVersion=”8.0.50727.762″/(tag)
    (tag)bindingRedirect oldVersion=”8.0.50727.42-8.0.50727.762″ newVersion=”8.0.50727.762″/(tag)
    (tag)/dependentAssembly(tag)
    (tag)/dependency(tag)

    (tag)/assemblyBinding(tag)
    (tag)/runtime(tag)
    (tag)/configuration(tag)

    ————————————————————————————

  17. jkalmbach Post author

    Remove all config-files and just remove the publicKeyToken!!!!!!

  18. Svetoslav Kyuchukov

    Hello Jochen,

    Thanks for the useful article. The described technique work also fine for deploying of debug versions, by working with corresponding debug folders and manifest files:
    (Microsoft.VC90.DebugCRT, Microsoft.VC90.DebugCRT.manifest, etc.)
    Currently I work on a VS2008 solution that contain 4 executables and 18 dlls, and deploying debugs is a practical (for Testers, PMs, etc. purposes).

    And further, even the Common Control Dll (comctl32.dll) can be deployed locally, skipping the WinSxS. This can be done with the following steps:

    1. Create a folder “Microsoft.Windows.Common-Controls” in deployment exe folder, for example
    MyApp\exe\Microsoft.Windows.Common-Controls

    2. copy comctl32.dll file from C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a folder
    into MyApp/exe/Microsoft.Windows.Common-Controls folder

    3. copy x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.Manifest file from C:\WINDOWS\WinSxS\Manifests folder
    into MyApp/exe/Microsoft.Windows.Common-Controls folder

    4. rename x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.Manifest to Microsoft.Windows.Common-Controls.Manifest

    5. remove publicKeyToken from this new manifest (Microsoft.Windows.Common-Controls.Manifest)

    6. in all dlls and exes manifests remove publicKeyToken from the section described “Microsoft.Windows.Common-Controls”.

    Now comctl32.dll is deployed locally, and WinSxS is bypassed.

    Best regards,
    Svetoslav Kyuchukov

    Eurorisksystems Ltd.
    Varna, BG

  19. Bruno

    Hi everybody,

    I am trying to solve this problem but I have a question. Where do I find the external manifest of my project? When I went to the Debug folder all I can find is app.exe.embed.manifest and app.exe.intermediate.manifest??? Or should I just create it myself???
    Thanks,

    Bruno

  20. jkalmbach Post author

    If you want an external manifest, you need to disable the embedding of the manifest. See Manifest options (Project-Properties|Manifest Tool|Input and Output|Embed Manifest: No)

  21. Bruno

    Hey,

    Sorry for this second message. I also noticed that my manifest file is looking for Microsoft.VC80.CRT & Microsoft.VC90.DebugCRT:

    I could find VC90.DebugCRT in (ProgramFiles\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedis\x86) the Visual Studio folder (VS 2008 Professional Edition) but I cannot find the VC80. Can anybody tell me what should I do???

    Thanks,

    Bruno

  22. jkalmbach Post author

    You have some kind of “bug” in one of your dependencies… you must not deploy debug versions!

  23. Pingback: Jochen Kalmbach’s Blog » Blog Archive » Deployment of VC2008 apps without installing anything

  24. Pingback: Sequence Ecowin Pro 6 | Application Distribution Blog

  25. Chronogps

    I followed the tutorial but I get a 0xC0150002 error (missing DLL I supposed). Any idea ?

  26. jkalmbach Post author

    Maybe you have forgott to remove the publicKeyToken? Or you have other DLLs which have a embedded manifest with the publicKeyToken?

  27. Pingback: links for 2010-07-31

  28. Pingback: App-V FAQ #31: Can I virtualize the .NET Framework or Visual C++ Redistributables? | Aaron Parker

  29. Pingback: Vs2008 compile the program can’t run out or need to install the vcredist_x86. Exe to run a solution

  30. Pingback: Sequence Ecowin Pro 6 | The knack

Comments are closed.