Share via

Building an MSI using WiX v3.0 that includes the VC 8.0 runtime merge modules

  • Article

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:

  1. Install Visual Studio 2005 Standard Edition or higher

  2. Download and install the latest build of WiX 3.0 from https://wix.sourceforge.net/downloadv3.html.  You need to install the ProjectAggregator2 MSI and then the WiX 3.0 MSI

  3. Launch Visual Studio 2005

  4. Choose File | New | Project...

  5. In the New Project dialog, select the WiX project type and then the WiX Project template to create a new WiX project

  6. In the WXS file that is created as part of the new project, add new <Merge> elements as children of the TARGETDIR <Directory> element for each one of the VC 8.0 runtime merge modules that you want to include in your MSI.  For example, to include MSVCRT, use the following items:

    <Merge Id="CRT" Language="0" SourceFile="c:\Program Files\Common Files\Merge Modules\microsoft_vc80_crt_x86.msm" DiskId="1" />

    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.

  7. For each <Merge> element that you addded in step 6, add a <MergeRef> element under the appropriate <Feature> element.  For example:

    <MergeRef Id="CRT" />

  8. Add any other information that you want to include in your MSI, save the project and build it using Visual Studio

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:

  1. WixProject1.wxs(10,0): Warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'c:\Program Files\Common Files\Merge Modules\policy_8_0_Microsoft_VC80_ATL_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module.
  2. light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
  3. light.exe(0,0): Warning LGHT1076: ICE30: The target file 'ansiatl.dll|ATL80.dll' might be installed in '[SystemFolder]' by two different conditionalized components on an LFN system: 'ansi_atl80.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E' and 'nosxs.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E'. If the conditions are not mutually exclusive, this will break the component reference counting system.
  4. light.exe(0,0): Warning LGHT1076: ICE82: This action SystemFolder.97F81AF1_0E47_DC99_FF1F_C8B3B9A1E18E has duplicate sequence number 6 in the table InstallExecuteSequence
  5. light.exe(0,0): Warning LGHT1076: ICE83: The keypath for Global Win32 SXS Assembly (Component_=uplevel.66332652_9C28_58B1_FF1F_C8B3B9A1E18E) SHOULD NOT be it's manifest file for assemblies other than Win32 Policy assemblies

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>

Comments

  • Anonymous
    February 14, 2007
    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.

  • Anonymous
    April 24, 2007
    I previously wrote a blog post about updated versions of the Visual C++ 8.0 runtime files that shipped

  • Anonymous
    February 29, 2008
    There are a several prerequisite dependencies that must be satisfied on a Windows system that does not

  • Anonymous
    February 29, 2008
    There are a several prerequisite dependencies that must be satisfied on a Windows system that does not

  • Anonymous
    January 26, 2010
    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

  • Anonymous
    November 15, 2010
    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.

  • Anonymous
    January 28, 2011
    "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: SourceFile="$(env.CommonProgramFiles)Merge ModulesMicrosoft_VC100_CRT_x86.msm"

  • Anonymous
    January 28, 2011
    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.

  • Anonymous
    August 24, 2011
    Hi, All! 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.

  • Anonymous
    August 25, 2011
    Hi Serg - I have the Microsoft_VC100_CRT_x86.msm along with all of the other VC++ MSMs at C:Program FilesCommon FilesMerge Modules on my computer.  Is that the location where you see the x64 version of this MSM?

  • Anonymous
    September 18, 2011
    In view of what AlexPerry mentioned above, what is the suggestion on including "Policy" msms?

  • Anonymous
    September 18, 2011
    Hi Venkat - I'd recommend not including the policy MSMs for the reasons that Heath Stewart and AlexPerry described in their comments above.

  • Anonymous
    October 09, 2012
    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!

  • Anonymous
    November 01, 2012
    Hello. 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? Thank you.

  • Anonymous
    November 02, 2012
    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.

  • Anonymous
    November 04, 2012
    Thank you very much.

  • Anonymous
    August 28, 2014
    Any one else get the errors LGHT0204 : ICE03: Table: MIME Column: Extension_ Missing specifications in _Validation Table (or Old Database) error LGHT0204 : ICE03: Table: MIME Column: CLSID Missing specifications in _Validation Table (or Old Database) error LGHT0204 : ICE03: Table: Class Column: ProgId_Default Missing specifications in _Validation Table (or Old Database)