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>
Hi Denis - The recommended option for this type of scenario is to use a chainer and install the Visual C++ redistributable before installing the MSI that has the service installation in it.
If you need to install everything in a single MSI, then you can schedule the InstallExecute action before InstallFinalize, and then schedule the StartServices action after those actions.
Thank you very much.