WiX Bootstrapper: skip bootstrapper UI, show MSI dialogs first - wix

We have had a somewhat complicated MSI installer (WiX) for a while and are now in need of calling certain executables after (and potentially before) the MSI. These executables must be ran outside of msiexec. So I have just started to get a WiX bootstrapper going that bundles the current MSI and then calls the EXE needed afterwards as follows:
<Bundle Name=".......">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<bal:WixStandardBootstrapperApplication
LicenseUrl=""
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension" />
</BootstrapperApplicationRef>
<Chain>
<MsiPackage Id="MainMSI" SourceFile="installer.msi" DisplayInternalUI="yes" />
<ExePackage Id="EXE1"
InstallCommand="...."
SourceFile="Exe1.exe" />
Since all the dialogs we have (license, options, etc) are in the MSI (and we want to keep it that way, for the most part), what's the best way to have the bootstrapper not show any UI before the MSI does? Currently I have a white dialog with a couple of buttons that are from the bootstrapper, but is there a way to tell the bootstrapper to not show any dialogs at the beginning or even to jump to the MSI right away?
After the MSI is done, I'd like to put up some dialog to show some progress on the EXE that are running and a "done" dialog. I guess that would have to come from the bootstrapper? how to do that? Or do I need to create a simple "done" MSI that shows a "done" dialog?
Thanks

I think it is not possible with StandardBootstrapper, but it is definitely possible with custom managed bootstrapper. In custom MBA you create the bundle UI yourself. In particular, when the switch /quiet is passed on the command line, you do not create the UI at all. But you may not create the UI or create some invisible UI even for the normal case.
However that will go against the Burn philosophy: all UI should be in bootstrapper and the MSIs should be dumb.

Related

Wix Installer: Bundled MsiPackage causing install bundle to attempt to run again?

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.
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.
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" –

WiX: Use Burn to recache broken MSI

We have a busted MSI in production that needs to be fixed via msiexec /fv package.msi before it can be properly upgraded.
I was hopeful that we could wrap this procedure in Burn but this Q and response from Rob appears that it might not be possible.
I tried:
<Chain>
<MsiPackage SourceFile="fixed-package.msi">
<MsiProperty Name="REINSTALLMODE" Value="v"/>
</MsiPackage>
</Chain>
But nothing happened.
I only need REINSTALLMODE=v and not REINSTALLMODE=amus as mentioned in the linked question, so I'm not sure if that makes a difference. The broken package has bad conditions that prevents uninstall and upgrades and this new one fixes that.
Have things changed in Burn since May '13 that recaching an existing MSI is now possible?
Thanks
You can also do it with a custom action. Just have the MSI extracted as temporary file in the beginning of the install for the new version, then execute a custom action to recache it, after which continue the installation. This is how I have done it so far.
However, I don't know if Wix has support for temporary files like Advanced Installer does (which is our tool), so you might need to build a custom action for that too.

How can i display my MSI's UI on Uninstalling from a Burn Bootstrapper?

I have a Burn bootstrapper which is installing a series of dependency MSIs and then my product MSI. The main product MSI has DisplayInternalUI="yes" which works great and allows me to display custom UI etc etc.
My problem is on uninstall. I'm making use of the FilesInUse dialog in my MSI to prevent uninstall while the application is running. However this dialog only displays if I uninstall using the MSI. If I try to uninstall using the bootstrapper the UI will not display.
Is there any way to make the bootstrapper call the MSI with full UI mode on uninstall?
Burn doesn't support that. There's typically no support for "full UI on uninstall"; instead, the UI for maintenance mode is shown. That could lead to the user doing something other than uninstall but there'd be no way for Burn to know that what it requested wasn't done.

Using bootstrapper with MSI ui

I have MSI file that is ready to install. It contains a customized UI that also collects data from user. As part of installation, i would like to install following things if missing
.Net framework 4.0
Microsoft Visual C++ 2010 Redistributable Package (x64)
From what I learned, bootstrapper should contain UI as well. How can I use bootstrapper for only initiating prerequisites stage and then proceed with MSI UI installation?
If you use the Visual Studio Setup and Deployment projects bootstrapper (GenerateBootstrapper related things) then it will show your MSI UI after installing the prerequisites. It's a pretty simple bootstrapper.
I believe the custom bootstrapper UI you are thinking about is the new Burn functionality in WiX v3.6+. Burn is a lot more powerful and can create single, seamless user experience for multiple chained packages (.exe's or .msi's or .msp's or .msu's). Using Burn you can create a very custom UI that does not show any UI from your chained packages. Alternatively, you can have Burn show the MSI UI. Basically, Burn is highly configurable but does require a bit of extra work (since WiX toolset doesn't provide everything out of the box, yet).
To show the MSI UI when running in a Burn-based Bundle you'll need to add DisplayInternalUI='yes' to the MsiPackage elements you want to display. For example:
<Chain>
...
<MsiPackage ... DisplayInternalUI='yes' />
</Chain>
If you are using the wixstdba (which is very common), it will show it's UI until it comes time to install the .msi package. Then the .msi package UI will pop-up on top and return back to the wixstdba UI to complete the Bundle install. You could provide your own Bootstrapper Application if you want to change the way that the Bundle based UI shows up.

Wrap an EXE installer inside a WIX msi

I found this article that shows how to call an EXE installer at the end of an installation done with a WIX installer.
Unfortunately, it does not quite work for me: the EXE does not start after the installation completes. Does anyone has a working example? Unless there is something easy to change from Mr. Ryan's example?
Any input would be greatly appreciated!
You can use the WIX v3.6 Bundle concept to handle this. You can read more about it here
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm
Basically you are packaging your WIX MSI and the EXE into a single WIX bundle package which can be then installed to the target machines.
I also wanted to keep the UI from the MSI so I added this code to start an exe installer for hardware keys. I know it goes against MSI Best Practices but this is the only one I intend on breaking. Hope this helps.
<Property Id="WixShellExecTarget" Value="[#myapplication.exe]" />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" Impersonate="yes" />
I then ran the custom action from a button click. Or you could schedule it to run after InstallFinalize.
Mr. Ryan here :)
in case this is of use:
this is the WiX project I made, to install Report Viewer 2010 using GPO (Group Policy)
http://www.natureireland.com/Downloads/StackOverflow/oRV2010Installer.rar
note: I used WiX version: Windows Installer XML v3.5
regards
sean