I have an application that uses the ms vc++ runtime. How should I install it on the end-user's system if it is not present? I was thinking of bundling it with the installer... but how would I do that as far as what to include? Is there some silent installer? If so, where can it be found? I can't seem to find it in the Windows SDK.
There is an interesting post about deploying the runtime libraries on the Visual C++ blog. The post is about VC8 so I'm not sure all the recommendations apply to VC9.
Here are your options according to Microsoft:
Use an .msi installer including the .MSM files for the VC
libraries you're using. These MSM
files install the libraries globally.
They also keep a reference count so
that the libraries are removed when
the last application using them gets
uninstalled.
Use "app-local"
deployment i.e. copy the
libraries and manifest files in your
application directory. This is a simpler
solution if you don't use an .msi
installer. Your app should still use the
system version of the libraries if they are more
up-to-date than your own.
Link everything statically (and avoid crt usage across dll boundaries)
Another option Microsoft discourage you from using is running the Visual C++ redist installer from your own installer.
I'm not sure what their reasons are. It will take a few extra megabytes and will not be reference counted but it still works very well AFAICT. You can pass the /q option to vc_redist_x86.exe to perform an unattended install (no user interaction).
It has it's own installation program. I've seen it usually run as a prereq step of a larger installer.
One way or the other, you need to list it in your manifest. So you might just as well deliver it as via SxS in your application rather than try to deliver a global copy to the target machine. SxS is a big hard subject, sadly. Hopefully someone will supply an answer with more details and I'll delete this one.
Related
I notice that Microsoft Visual C++ runtime libraries are duplicated all over my computer, eg: at the following locations:
C:\Windows\System32
C:\Windows\SysWOW64
C:\Program Files\Common Files\microsoft shared
C:\Program Files (x86)\Mozilla Firefox
C:\Windows\WinSxS\amd64_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_b157f27efd203c73
C:\Windows\WinSxS\x86_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_553956fb44c2cb3d
Why is this? I thought a specific .dll could only be registered ONCE with windows? Is that not the case? Can you really register the same .dll from multiple locations?
I uninstalled an old version of Skype which had the C++ .dll's in its own folder. But doing so caused a whole load of other programs to break (eg Adobe Acrobat, etc). I fixed it by repairing the C++ 2015 redistributable from Control Panel's Programs & Features window. But while checking the damaged files were re-created and re-registered, I discovered so many versions. How do I know which one is registered with Windows?
If I wanted to write code that referenced those .dll's, which one would it use?
I found a hint of reason for this in this article.
Consider this scenario: you install program “A” and it uses library
version 1. You then install program “B” and it also uses library
version 1, so it doesn’t need to install it – it can just use the copy
that’s already there courtesy of program “A”. Now you uninstall
program “A”. Three things can happen:
It uninstalls the library because it installed it and it should clean
up after itself, not realizing that another program relies on the library. Program “B” breaks as a result.
It never uninstalls the library because another program might be using it. As a result, libraries check in, but they never leave.
We devise some method of tracking how many installed programs are using the library, and only remove it when the last one is uninstalled. Unfortunately, any single program’s failure – be it a programming error or a failure to install or uninstall properly – breaks this technique. At best, you’re left with copies of the library you no longer need, and at worst, uninstalling one program can cause one or more other unrelated
programs to fail.
It’s a mess. In fact, it’s such a mess that most
programs now don’t bother to try and share at all.
Putting Your Fate in Someone Else’s Hands:
Ultimately, application vendors realized that by relying on shared libraries like this, they were putting their fate into the hands of every other application that happened to use the same version of the same library. If only one of them made a mistake, and the library was accidentally removed or updated when it shouldn’t have been, it put all the others at risk.
So, application vendors typically now install their own copy of the
library that they manage and that they can rely on. Disk space is
cheap – much cheaper than the errors and frustration that were
happening when they tried to share.
So now, on my machine, many different applications all carry with them their own copy of the Microsoft Visual C++ Runtime.
And each is more stable as a result, by virtue of being in control of
their own destiny.
However, it remains unclear how dll files can be registered with the same name but from different locations. I did not think this was possible, but perhaps it is.
I am working with a setup project of Visual Studio 2015. I want to distribute the 2015 C++ library, vc_redist.x86.exe. But I don't want user to be aware of this pre-requisite, so the idea is that while he is running the .msi, the C++ library will be auto-installed.
I have been reading about the merge modules, but this cannot fix my problem because the setup.exe should be run. Please, could anybody tell me how to deal with this?
Many thanks!
You'll need to change (or create your own custom one) the standard bootstrapper that has documentation starting here:
https://msdn.microsoft.com/en-us/library/ms165429.aspx
The bootstrapper packages contain the detection and install logic for the redistributables. For example, the \Bootstrapper\Packages folder has VC redist folders, each with a product.xml and a package.xml about installing them as prerequisites. They have standard command lines such as:
Command PackageFile="vcredist_x64.exe" Arguments=' /q:a
and you can substitute that command with something like those listed here:
http://asawicki.info/news_1597_installing_visual_c_redistributable_package_from_command_line.html
that show the quiet options (as do standard Microsoft docs somewhere).
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
I'm using third party libraries that I obtained well before KB2465367 came out. My development computer has been updated with KB2465367 so all the binaries I generate seem to now be dependant on 8.0.50727.5592 of the CRT (the 2465367 version of the CRT).
Now, when I want to deploy this application I'm using the 8.0 CRT merge module (also updated by 2465367). This installs 8.0.50727.5592 versions of MSVC libraries (like msvcrt80.dll).
But, when I run my application on a machine that's never had the VC runtime installed, it complains about "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." I've traced this back to a system entry in the event log: "Generate Activation Context failed for C:\Program Files\MyCompany\MyApp.exe. Reference error message: The operation completed successfully." under the source "SideBySide".
Of course, this update has basically meant I'm dead in the water.
How do I proceed from here? Do my clients need to install 8.0.50608.0 version of the CRT after installing my application because the 3rd party libraries need 8.0.50608.0 and the MSM I used didn't include it?
In my circumstance I'm using How To: Install the Visual C++ Redistributable with your installer which only describes using a single MSM. It's recommended that a policy MSM also be used to redirect any DLLs dependant on older versions of the runtime.
See also http://lynk.at/jlqsKx
This is the same thing happened when MS rolled out KB971090.
A simple solution is to remove the KB2465367.
You can reference more information about KB971090 and KB2465367 at here.
There is an uninitialized data bug in the patch that can cause DLL load failure.
Your installation program have to use two merge modules:
The runtime libraries, and
The policy file which redirects all older versions of the runtime to the new version.
The redistributable package vcredist_xxx.exe installs both the latest version of the libraries and the policy files.
You cannot assume the VC libraries are available on users machines, therefore you always have to install them. Otherwise your application won't run.
I'm developing in an environment that is severely constrained, but the developers also have tight control over.
VCRedist_x86.exe - A 4Mb redistributable - is no fun (four hours to transfer). I'd really prefer to just redistribute MFC90.dll, msvcm90.dll, msvcp90.dll and msvcr90.dll - that's more like 2Mb. However, Redistributing Visual C++ Files says:
It is not supported to redistribute C/C++ applications that are built without a manifest. Visual C++ libraries cannot be used by C/C++ applications without a manifest binding the application to these libraries. For more information, see Choosing a Deployment Method.
My original plan of copying the DLLs into the program's working directory doesn't seem to
work in this brave new world of manifests.
My next guess is to bodge up the registry entries required to populate the files into the WinSxS directory and populate it myself (rather than using the 4 meg program).
[edit] The software is frequently updated, so DLLs are strongly preferred to static linking. [/edit]
How can I sucessfully distribute the necessary files but keep the overhead down?
[I'm the current SxS maintainer at Microsoft]
I would strongly suggest against removing the publicKeyToken attribute from manifests. Private deployment of the dlls will work just fine with this attribute left intact.
However, removing it will prevent your app from benefiting from security updates should there be a newer version of the CRT installed centrally on the target machine, as the dependencies will no longer match up.
So, to summarize: it's safe to embed your manifest, with the default. Copy the CRT manifest + DLL files directly into your executable's directory, with no edits. That's it. Compatible Win2k+.
We use this: Howto: Deploy VC2008 apps without installing vcredist_x86.exe
Essentially
Don't embed a manifest in your exe files.
Copy the C++ DLLs and their manifests to your app's directory.
Remove the "publicKeyToken" from all manifests (yours and Microsoft's).
If necessary, change the version info in your app's manifest files to match the Microsoft manifest files (or vice versa)
Specify /MT (Multithreaded) for the "runtime library" setting in the compiler property page. This statically links against the runtime library so you don't have to install the redistributable.
Install them as private assemblies. See here:
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Note that if you don't need all of the DLLs provided you can modify the manifest files to only reference the ones you need.