Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I was recently asked a question by a customer who was building an MSI using WiX v3.0 and the Votive add-in for Visual Studio 2005. They were trying to consume the VC 8.0 runtime merge modules (MSMs) into their MSI, but were having trouble figuring out exactly how to configure their WiX project so that it would correctly consume these MSMs and install the VC 8.0 runtime files as part of their MSI-based setup.
I looked around a little bit and found these instructions written by Nikola Dudar on the Visual C++ team here at Microsoft. However, the instructions in that blog post are based on WiX v2.0, and the equivalent steps in WiX v3.0 are much more straightforward, so I decided to post a set of steps that can be used to create an MSI in WiX v3.0 and Votive that consumes the VC 8.0 runtime MSMs:
When building an MSI that consumes the VC 8.0 runtime MSMs using Votive v3.0 in Visual Studio 2005, you may see several of the following types of warnings in your build output:
The first type of warning indicates that actions with the same name exist in multiple merge modules. Windows Installer requires unique action names, and when attempting to merge MSMs that contain multiple actions with the same name, Windows Installer will exclude all but the first action. In this case, the exact same SxsInstallCA and SxsUninstallCA actions exist in all of the VC 8.0 runtime MSMs, and so all but the first ones are excluded from the merging process. However, all of these actions are identical and execute the same code behind the scenes, so it is safe to ignore this type of warning because you will not be losing any required functionality during the merge process.
The second type of warning indicates that some identifiers are longer than the maximum values specified in the _Validation table of the MSI. The documentation for ICE03 indicates that Windows Installer does not internally limit the column width to the specified value, so these warnings can be safely ignored.
The third type of warning helps prevent authoring different components that install the same files to the same destination folder (which would violate Windows Installer component rules). However, in the case of these VC 8.0 MSMs, the components have conditions that are mutually exclusive (Version9x and VersionNT < 501) so the component rules will not be violated and these warnings can be safely ignored.
The fourth type of warning indicates that actions contain duplicate sequence numbers in the InstallExecuteSequence table. When actions have duplicate sequence numbers, there is no guarantee about what order they will be run in. However, in this case, the actions have no order dependencies and it is safe to ignore these warnings as well.
The fifth type of warning helps prevent authoring incorrect keypath files for Win32 global assemblies that are installed to the WinSxS component store. This warning indicates that they keypath should not be a manifest file unless the assembly is a Win32 policy assembly. In this case, the assembly is a Win32 policy assembly, so these warnings can also be safely ignored.
Note: it is possible to suppress the above warnings by configuring some settings in the WiX linker project property page in Visual Studio. In general, however, I advise against doing that because if you enable suppressions, you might end up missing other warnings or errors in the same categories that are not safe to ignore.
<update date="2/12/2008"> Added information about ICE03 warnings that can occur when merging the VC 8.0 MSMs that I missed when I originally wrote this post. </update>
<update date="2/11/2009"> Removed references to policy MSMs because the general recommendation is to not include policy MSMs when redistributing the VC runtime files. </update>
It's important to note that the policy MSM should be merged after the payload, if merged at all. It is recommended that you do not merge the policy MSM as this will redirect all applications depending on the related native assembly to that version. If you have no major reason to affect every application, merge only the payload MSM. I'll be doing a post or two on the situation as a whole very soon.
I previously wrote a blog post about updated versions of the Visual C++ 8.0 runtime files that shipped
There are a several prerequisite dependencies that must be satisfied on a Windows system that does not
Realise that this post was a long time ago but it was very useful to me recently (only just moved to vs2008 from 2005) - However there is an issue in not merging the policy files for the CRT.
By default vc90 (version in vs2008) will request the oldest version of CRT which is compatible for the widest coverage (on my system CRT version requested is 9.0.21022.8) - however the version in the msi will be the more recent version (on my system is 9.0.30729.4148).
If the policy file is not merged then this will not load at run time (the compatability of versions is controlled by the winners value in the registry which is set in the policy).
Alternatively you may use a #define to change the version of CRT that is required so it does match but merging the policy as well seems simpler
Where did you put the #define... in the manifest file? I am using Visual Studio 2008, but I hesitate to merge the policies due to Heath Stewart's comment above about affecting other applications also installed on the target computer.
"Note: You will need to change the SourceFile attributes to point to the exact locations of the MSM file on your system. This location depends on what partition you have your OS installed to."
Would it not be better to simply use environmental variables? This works for me on three different setups:
Hi Rune - Yes, this would work too, thanks for suggesting this! I wasn't familiar with the WiX environment variable syntax back when I originally wrote this blog post.
Where i can find file Microsoft_VC100_CRT_x86.msm ? I was listed all files msm on my PC? and found only Microsoft_VC100_CRT_x86_x64.msm. But this file need use fo x64 applications.
Hi Serg - I have the Microsoft_VC100_CRT_x86.msm along with all of the other VC++ MSMs at C:\Program Files\Common Files\Merge Modules on my computer. Is that the location where you see the x64 version of this MSM?
In view of what AlexPerry mentioned above, what is the suggestion on including "Policy" msms?
Hi Venkat - I'd recommend not including the policy MSMs for the reasons that Heath Stewart and AlexPerry described in their comments above.
A MSVCRT installed via merge module WON'T get detected (and updated) from Windows Update. Do you really want all your applications to be vulnerable until you incorporate an updated MSM in your package, then urge your customers to manually update their systems?
The same argument holds AGAINST the recommendation not to include policy MSMs: the newer MSVCRT contains (security) fixes. If your application fails, it has to be fixed anyway!
And: newer versions of the MSVCRT are compatible to their older versions.
If not, it's Microsoft's fault. Sue them, and let them fix!
There is the service installation in my install-package. I also have choose to start the service automatcally from installer. I've got a problem. The installer starts my service before CRT installation. How can I force installer setup CRT before service startup?