0
votes

I have the following very basic WIX 3.11 bundle defined at the minute and I have removed the execpackages that fire before the MSI is installed as the problem I'm about to describe only occurs with the MSIPackage command and the specific Third Party MSI I'm using.

<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
        xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
  <Bundle Name="ACME APP 32Bit" Manufacturer="ACME CORP" Version="1.0.0.0" UpgradeCode="0B736949-AE50-46B0-A534-42C9672FAF1F" IconSourceFile='..\Common Files\Images\icon.ico'>
    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLargeLicense">
      <bal:WixStandardBootstrapperApplication
        LicenseFile="..\Common Files\Documents\EULA.rtf"
        ShowVersion="yes"
        LogoFile="..\Common Files\Images\logo-64x64.png"    
        LogoSideFile="..\Common Files\Images\logo-64x64.png" 
        />  
    </BootstrapperApplicationRef>
    <Chain>
        <MsiPackage Id="TP32BIT" SourceFile="ThirdParty.msi" Visible="no" />

    </Chain>
  </Bundle>
</Wix>

What is happening is after the bundle deploys the MSI and whilst the Installation completed successfully dialog is present , the modify setup dialog again (repair uninstall cancel ).

It only appears to happen with the third party MSI that I need to install. I don't have control over this MSI and nor can I get support on changing from the manufacturer at this time.

I've replaced the MSI with another random product and it doesn't result in the same issue. Its deployed without effectively attempting to run the bundle installer again.

I've run the Third Party MSI from the command line and checked it's return code on instillation and it returns 0.

I'm baffled as to whats causing the installer to think it needs to run itself again on completion of this MSI. Non of the UUIDs are in conflict and I don't think there's anything wrong in my xml.

If anyone can shed some light onto this I'd appreciate it. Currently the only thing I can think of doing is attempting to deploy this specific MSI to the platform via a execpackage approach that runs the msiexec from command line but that completely negates the reason I'm using a bundle in the first place.

Thanks in advance.

2
Added an answer which is more a follow-up question than an answer. Please check it out and provide some more information and context.Stein Åsmul

2 Answers

0
votes

I am a little bit confused reading this.

  • Does the problem manifest itself if you run ThirdParty.msi interactively with full setup GUI outside the Burn Bundle?
  • In other words a regular installation, that is not invoked via command line but run by double clicking the MSI and then clicking through the setup GUI.

I suppose it is possible that some fancy event in the setup complete dialog kicks off a custom action that does something crazy. Is this an MSI that we can take a look at? Can you provide a download location? (no promises though).

When the setup is run in silent mode, the GUI sequence does not run - which could explain why things work in silent mode - if this is indeed the case.

0
votes

Turns out it's a known bug in WIX that is triggered by the 3rd Party MSI. github.com/wixtoolset/issues/issues/5266 This MSI can't be changed and has to deploy it's content using this mechanism. I've been able to create a work around to resolve the issue as the installer starts 2 new instances of Wix after the MSI completes so I'm tracking the process IDs and killing anything "unknown" –