0

I am including the VS 2005 merge modules into an MSI. The code is in place and the MSI builds. 

<Fragment>
  <DirectoryRef Id="TARGETDIR">

    <!-- 
    WiX docs say "There is generally no need to include the policy MSMs as part of the installation.", but, the former Installshield 
    project did include it, so, including here now. Remove it if it's actually not required. 
    http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html
    -->
    <Merge Id="VCRedist2005_32" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\Microsoft_VC80_CRT_x86.msm" DiskId="1" Language="0"/>
    <Merge Id="VCRedist2005_64" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\Microsoft_VC80_CRT_x86_x64.msm" DiskId="1" Language="0"/>
    <!--
    <Merge Id="VCRedistPolicy2005_32" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\policy_8_0_Microsoft_VC80_CRT_x86.msm" DiskId="1" Language="0"/>
    <Merge Id="VCRedistPolicy2005_64" SourceFile="$(var.RESOURCES)\MergeModules\VS2005\policy_8_0_Microsoft_VC80_CRT_x86_x64.msm" DiskId="1" Language="0"/>
    -->

  </DirectoryRef>
</Fragment>

And in my Product.wxs:

    <Feature ...>
        <ComponentRef Id="Client_Registry" />
        <?if $(var.Product) = xx ?>
            <MergeRef Id="VCRedist2005_32"/>
            <MergeRef Id="VCRedist2005_64"/>
            <!--
            <MergeRef Id="VCRedistPolicy2005_32"/>
            <MergeRef Id="VCRedistPolicy2005_64"/>
            -->
        <?endif?>
    </Feature>

I am concerned about two warnings though:

1>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do not find CRT.Policy.63E949F6_03BC_5C40_FF1F_C8B3B9A1E18E@0 v in ModuleSignature table
1>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do not find CRT.Policy.4F6D20F0_CCE5_1492_FF1F_C8B3B9A1E18E@0 v in ModuleSignature table

Two messages because I am including both the 32 and 64-bit merge modules.

I did not add the policy files because the wix page suggests not to. A MS blog page also backs that up. But, then there are pages such as this one, where the advice is TO include them.

So, I am unsure how to proceed. Should the policy files be included or not? And if not, why not?

Jon
  • 1,675
  • 26
  • 57

1 Answers1

0

I've always preferred to bootstrap the vcredist runtime instead. Keeps my MSI all nice and clean with no issues.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • That could be done (we do it for the next-gen product which depends on VS2015, which has no MSM)... but then, I'd have to (I gather, from what I've read and tried to understand) duplicate the MSI gui, which already presents the user with install options - and works - into a new application which I'd have to write myself. Seems like a massive effort (even to get approved) for very little payback (the installer would simply look and act the same). Right now, we're ignoring the obvious - that we cannot modify the current installation (have to remove and reinstall). Easier to go the MSM route! – Jon Sep 07 '16 at 17:06
  • You can create a burn bootstrapper that shows the primary MSI UI. Burn is really good at chaining and managing but when you want the very simple scenario of a prereq and a standard MSI I find InstallShield setup prereqs bootstrapper is easier. – Christopher Painter Sep 07 '16 at 19:35
  • That's what we are forced into for the VS2015-built version of the app. The problem is, we cannot "modify" the installation. The ARP entry (for the bootstrapper) does not offer the modify and repair options, so we have to remove and reinstall the app to change the install options. If I hide the bootstrapper ARP entry (just showing the MSI entry), then we can modify/repair, but Uninstall does not remove the bootstrapper from the system, leading to a failed subsequent install (until you properly remove the previous version). Again, it's easier and preferable to go the MSM route! – Jon Sep 09 '16 at 14:12