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.
Related
If you add ActionData to the Subscribe event in Edit Control on Wix,
the line is written and erased. I want the ActionData log to continue to be written as a scroll.
Burn: WiX Burn allows you to write your own GUI to run your installer. You should be able to implement whatever you want in terms of GUI if you go down that path. However: installers run quicker and quicker as IO becomes better, are you sure this is time well spent? I'd say just use logging and be done with it? See my comments above for your question.
Burn Bootstrapper Appliation: There are not that many samples I know about for Custom WiX Burn Bootstrapper applications. Here are two:
Write your own WiX Burn setup GUI application (advanced)
https://github.com/rstropek/Samples/tree/master/WiXSamples/CustomBurnUI
Documentation: For documentation go online, or better yet open WiX.chm and locate section "Building Installation Package Bundles".
Here are two past answers that I would suggest you at least skim:
Ways to customize your WiX GUI (do read this one for overall understanding of MSI GUI)
Custom GUI - WiX Burn, Installshield Suite Project, Advanced Installer - their options
The Implementation of a custom GUI for an MSI depends on the core MSI API function MsiSetExternalUI function. It allows what Burn is doing - making a custom GUI. Throwing in an SDK sample too:
MSI SDK Sample: Some details on the MsiSetExternalUI function (serverfault answer). Concrete code sample to handle Windows Installer messages: https://learn.microsoft.com/en-us/windows/desktop/Msi/handling-progress-messages-using-msisetexternalui. This is MSI API calls direct - nothing to do with Burn as such, Burn makes use of these calls.
Links: Link overload - as usual - but here is an example of a custom Burn theme - as opposed to a custom bootstrapper application. This changes the look of the standard Burn bundle.
https://github.com/frederiksen/Classic-WiX-Burn-Theme
SQL Server named instance with Visual Studio 2017 Installer project (just for inclusion)
Native Windows Installer UI doesn't support this. You would need to create a custom UI handler to display it the way you want.
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 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 already made a MSI installer with WiX using a custom WPF UI with the EmbeddedUI element. It is similar to the sample found in src/DTF/Samples/EmbeddedUI.
I would now like to have a bootstrapper that checks if .NET 4 is installed and install it if it's not, and then launch my MSI.
It looks like Burn would override my WPF EmbeddedUI in order to chain the .NET 4 and MSI installations into a single installation with a single progress bar. I know that I could have a managed application to change the UI of Burn then pass parameters to my MSI but the problem is that I would like my UI to be in WPF which relies on .NET, and if the whole bootstrapper relies on .NET then the user couldn't even open the bootstrapper if he doesn't have it installed in the first place.
What I would like is the bootstrapper to install .NET if needed with a simple UI like Wixstdba, and then launch my MSI as it is, with its own WPF EmbeddedUI, without chaining it with the .NET installation. I don't mind that both installations would have their own progress bar, I would just like to be able to use my WPF EmbeddedUI for the installation of the main application.
Would that be possible. How? Thanks!
If you want your WiX bootstrapper to display the UI of your installer, set the DisplayInternalUI attrible of the MsiPackage to true. That solution does have the downside of displaying two UIs during install though.
You can also create a managed bootstrapper application using WPF and .NET. Burn provides a way to basically bootstrap itself and install .NET before displaying your custom UI.
I have created a bootstrpper using the dotNetInstaller tool. The created bootstrapper internally has these installers:
.NET Framework 4.0
SQL Server Express
Now through WiX, what are the steps that I need to follow to invoke the above Bootstrapper from WiX?
You should not invoke a bootstrapper from WiX - that has no sense. The idea behind the bootstrapper is to "bootstrap" the prerequisites of the installation (.NET and SQL Express in your case) and the main installation package. The main package you generate with WiX should be launched from inside the bootstrapper when the prerequisites are checked and optionally installed.
See this article for better understanding how to start with bootstrapper authoring with WiX.
If you are using WiX to create installers, I would suggest using WiX to create your bootstrapper as well.
http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm
You can only invoke packages from using bootstrapper, you can't invoke it from WiX. By the use of dotNetInstaller you can easily invoke one after another. One of the process as #Yan introduced. By the help of prerequisites folder. It is a very efficient and popular process. But what can I suggest for you, invoke link instead of folder. So your installation full package wouldn't not so bulky. Whatever the msi need it can directly download from internet and install it one after another. Follow the link.
http://www.codeproject.com/Articles/5116/dotNetInstaller-Setup-Bootstrapper-for-NET-Applica