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.
Related
I have an msi bundled with prerequisites using Wix bootstrapper. After installing the wix bootstrapper application, if i relaunch it again i could do only repair and uninstall. But i need to have modify option also.
In MSI i tried setting the property REINSTALLMODE as "vamus". after doing so, i was able to change / repair/ uninstall w.r.t. msi.
But bootstrapper application doesn't show modify option.
On relaunching the installed wix bootstrapper application, i am expecting to have below options.
change, repair & uninstall.
A modify option makes only sense if you want to remove or add features included in an msi. May be a solution would be to set up your own bookkeeping on installed features and showing this list to the user in a custom bootstrapper application.
Another way to handle this situation may be to show the msi installation dialog which should show a "modify" dialog option.
I'm a bit confused about how wix burn and the main installer are expected to interact with each other. I'm new to wix and windows installer technology in general.
Based on the examples I've seen I was under the impression the burn application would install prereqs then switch to the main installer. However I've seen comments from searches that when using the burn application the main installer becomes secondary and the burn UI should be used instead. This is reinforced by the behavior of the burn application. What I mean is the burn application has it's own license agreement, ARP entry, hides the main installer by default, and has it's own change/repair entry.
This has me confused because the burn application is lacking a lot of functionality the main installer has through MSI. Some functionality I would consider essential such as feature selection, directory selection, and changing features. But this is absent from the burn application.
I feel if I used the burn application as the primary I'd have to recreate the UI, while if I used the main installer for prereqs (if possible) I'd have to recreate the functionality burn provides. Neither approach is desired, so I am wondering how other users of wix handle large projects. Is it standard to write your own custom burn UI? Any help that might clear up this confusion would be greatly appreciated.
Common practice would be to use the Wix bootstrapper (burn) specifically for installing software that is necessary to run your main application, first and automatically.
You would indeed use the main MSI produced by Wix to install your main application. You would use one of the UI (dialog set) sequences already available in Wix. The dialog set will be applicable only for the main MSI, because again, the bootstrapper's main responsibility is to install pre-requisite software for your application to be able to run.
The whole installation process involving your application MSI in conjunction with the bootstrapper executable would be as follows:
Pre-installation
You would build your application MSI.
You would make sure your MSI is specified in your bootstrapper .wxs file.
You would build a Wix bootstrapper executable file which, if correctly set, would
include your appplication MSI.
Installation
You simply run the bootstrapper executable file.
All pre-requisite software will be installed first.
Your main application MSI will now be executed. The user will now be able to set e.q. the installation directory of your application through the dialog sequence of your main MSI (including the other points you've mentioned, if the correct dialog sequence set has been selected before building).
Hope this helps to clear out things a little bit!
I have created a Wix Burn app that I am installing two MSI's with. Works great.
The MSI files install properly
The Wix Burn app registers with ARP.
The MSI files do not register with ARP
I can do Major Upgrades
I can install and uninstall manually with a local copy of the Wix Burn app
I can programmatically execute the Wix Burn app to uninstall (using /x)
The Problem:
I know two way to uninstall using a Wix Burn app:
Click on the Uninstall button in ARP (requires user involvement)
Launch a copy of the Wix Burn app that installed the product
I see in the Wix Burn log that Windows caches my Wix Burn app install in much the same way that MSIEXEC will cache MSI files. Is there a way to programmatically ask Windows or MSI to use the cached version of the Wix Burn app to do the uninstall?
A Possibility:
Presumably I could use MsiGetProductInfo() to get a path to the cached Wix Burn app. To do that, however, I need my app's Product Code. However, Product Codes are not attributes of elements in Wix so I am not seeing how to get a Product Code for a Burn package.
You might be able to solve this by iterating through the Uninstall registry entries. The process is:
Open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
Iterate through the sub-keys searching for an entry where the Publisher and DisplayName matches your product.
If you find an entry, read the value of QuietUninstallString and run that as a command. For a WIX burn installer this is typically in the form C:\ProgramData\Package Cache\{GUID}\SetupProgram.exe /uninstall /quiet.
If you are using a 64 bit operating system you will also need to search HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.
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.
I have a working WiX installer with a custom UI using a WixUI_Mondo_MyApp.wxs file. I have to extend my installer to also run another exe installer. I understand Burn is the way to do this.
I created a Burn project that chains my original MSI with the custom UI (using DisplayInternalUI="yes"), and that works fine. But I don't want two UIs popping up (the Burn default UI, and my MSI UI), and I need to get some info from the MSI UI to determine if I should install the other exe (it will listed as one of the features).
I suppose the proper solution would be to migrate my UI code from my MSI to my Burn project, but I can find no docs on describing how to do this.
Thanks in advance.
There is no migration path; MSI UI is declarative using the MSI UI tables and Burn supports arbitrary code in a bootstrapper application. If you have any logic in your UI customizations, you'd have to write a custom bootstrapper application to get that in a bundle.