[wix-users] Burn Bootstrapper Repair Hangs on MSI Failure

[Rob Mensching]

There was some discussion in WiX v4 about ways to re-implement Burn and the BA's interaction with Windows Installer Internal UI.

As it is, DisplayInternalUI has lots of "edge cases" (that aren't terribly edge) where it simply won't do the right thing. It was introduced thinking it would be easy (famous last words).

Jacob's disdain is not misplaced.


-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Hoover, Jacob via wix-users
Sent: Thursday, April 9, 2020 11:50 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: Re: [wix-users] Burn Bootstrapper Repair Hangs on MSI Failure

DisplayInternalUI="yes" is evil.

When it fails the first time, and rolls back the failing MSI, but the Bundle is in ARP/registered.

When you run it a second time, it offers repair because of the ARP registration.

DisplayInternalUI="yes" sucks.  10 to 1 says if you let the bundle be the proper UI, this wouldn't be an issue.

If you can submit a test case, someone might have time to look into it (or you could offer some time and join in on the wix-dev's meetings), though I have 0 passion for DisplayInternalUI.

Also, if you need this as a priority and don't have the time or expertise to learn burn, there's also the option of paying http://firegiant.com to do it.

Did I mention that DisplayIntrernalU is an abomination and an insult to the concept of a BA and a unified UX?

From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Tyler Gustafson via wix-users
Sent: Thursday, April 9, 2020 1:34 PM
To: wix-users at lists.wixtoolset.org
Cc: Tyler Gustafson <Tyler.Gustafson at comtechtel.com>
Subject: [wix-users] Burn Bootstrapper Repair Hangs on MSI Failure

Good morning,

I've got a Burn Bootstrapper with a chain element that looks like this:
<Chain DisableRollback="yes">
<MsiPackage Id="WorkingMsi" SourceFile="Working.msi" DisplayInternalUI="yes" Vital="yes" Visible="yes" /> <MsiPackage Id="FailingMsi" SourceFile="Failing.msi" DisplayInternalUI="yes" Vital="yes" Visible="yes" /> </Chain>

I've designed Failing.msi with a CustomAction which will intentionally fail the install:
<CustomAction Id="FailingAction" Directory="PRODUCTDIR" Execute="deferred" Return="check" ExeCommand="[SystemFolder]cmd.exe /c "COLOR 00 > [PRODUCTDIR]FailingAction.log"" /> <InstallExecuteSequence> <Custom Action="FailingAction" After="InstallFiles">(NOT Installed) OR (Installed AND NOT REMOVE~="ALL")</Custom> </InstallExecuteSequence>




1. The first time I run the bootstrapper, I see a window from the UI of the Failing.msi at the appropriate point; "There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor."
After pushing ok, the bootstrapper shows an error message "One or more issues caused the setup to fail. Please fix the issues and then retry setup. For more information see the log file. 0x80070643 - Fatal error during installation." Pushing Close exits gracefully. All of this is expected behaviour.


1. If I then try to run the bootstrapper again, I get a Repair option (which I push) because the bootstrapper was intentionally not rolled back and removed from system (DisableRollback="yes")


1. This time, it does not show me the window indicating there is a problem from step 1, but instead, hangs saying "Please wait while Windows configures Failing". When I mouse over that window, it updates the title bar from "Failing" to "Failing (Not Responding)". This is not expected behaviour.


1. I try to push the cancel button and get the standard windows dialog asking if I want to close the program or wait for it to respond and I choose to close the program.



1. Now I get the bootstrapper UI showing me the message that was displayed by the msi's UI from step 1 "There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." Pushing OK closes the program as expected.


1. Program flow starts from step 2 every time I run the bootstrapper now, unless I uninstall it from add/remove programs. If I do that, program flow starts over from step 1.


I think I'm seeing a bug with the interplay of bootstrapper repair, and passing messages back from the msi. I can't find this listed as a bug anywhere but I'll admit I'm not sure exactly what search terms to use. Any insight would be appreciated.

Thanks,
Tyler Gustafson
NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and / or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media.

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/<http://www.firegiant.com>
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/