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
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel> </requestedPrivileges> </security> </trustInfo> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30411.0" processorArchitecture="x86"></assemblyIdentity> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.30411.0" processorArchitecture="x86"></assemblyIdentity> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity> </dependentAssembly> </dependency> </assembly>
Microsoft.VC90.CRT.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <noInheritable /> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30411.0" processorArchitecture="x86" /> <file name="msvcr90.dll" /> <file name="msvcp90.dll" /> <file name="msvcm90.dll" /> </assembly>
Microsoft.VC90.MFC.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <noInheritable /> <assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.30411.0" processorArchitecture="x86" /> <file name="mfc90.dll" /> <file name="mfc90u.dll" /> <file name="mfcm90.dll" /> <file name="mfcm90u.dll" /> </assembly>
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.
May 3rd, 2008 at 17:59
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”
May 3rd, 2008 at 18:04
Hi Koro,
yes, we are moving from DLL hell to manifest hell… but the problem is the same…
Also, msvcrt.dll was *not* shipped with the OS; or at least mostly not the version you will require (at least for win95)! The same is true for mfc dlls. See:
http://blogs.msdn.com/oldnewthing/archive/2008/01/11/7065021.aspx
May 4th, 2008 at 18:15
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…
May 5th, 2008 at 20:15
[…] Jochen Kalmbach’s Blog Infos about Windows development and dotNET Framework « Howto: Deploy VC2008 apps without installing vcredist_x86.exe […]
June 19th, 2008 at 09:21
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 ?
June 19th, 2008 at 09:23
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″
June 19th, 2008 at 13:38
Solved !
here :
http://blogs.msdn.com/nikolad/archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx
September 15th, 2008 at 14:07
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
October 16th, 2008 at 18:21
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 ?
January 17th, 2009 at 18:50
[…] Projekte Guten Morgen, das hat mich auch einige Zeit geärgert, bis ich diese Lösung fand: http://blog.kalmbach-software.de/200…redist_x86exe/ In meinem Fall reichte es, die CRT statisch einzubinden. Viel Erfolg, Klaus On Mon, 20 Oct 2008 […]
January 18th, 2009 at 17:50
[…] manifests and local DLL deployment: Howto: Deploy VC2008 apps without installing vcredist_x86.exe http://blog.kalmbach-software.de/200…redist_x86exe/ HTH, Giovanni "philip" <mfc> ha scritto nel messaggio news:%23QgF6Bc8IHA.4140… […]
January 31st, 2009 at 00:20
thanx a lot mate !!! it definitly works. Great guide for looser as I am
May 5th, 2009 at 06:59
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.
May 5th, 2009 at 08:26
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!!!
May 6th, 2009 at 07:14
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.
May 6th, 2009 at 07:16
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!
May 6th, 2009 at 15:19
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…
May 6th, 2009 at 15:22
/*
Application.exe.manifest
Application.exe.config
*/
May 6th, 2009 at 15:27
assembly xmlns=”urn:schemas-microsoft-com:asm.v1″
manifestVersion=”1.0″
May 6th, 2009 at 15:33
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)
————————————————————————————
May 6th, 2009 at 17:22
Remove all config-files and just remove the publicKeyToken!!!!!!
May 27th, 2009 at 20:33
For appLocal deployment, without removing the publicKeyToken, see:
Deployment of VC2008 apps without installing anything
http://blog.kalmbach-software.de/2009/05/27/deployment-of-vc2008-apps-without-installing-anything/
August 21st, 2009 at 12:20
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