Is there a reason that the bootstrapper is an exe as opposed to an MSI? And, is there a way to instead generate a MSI?
I need to have multiple localizations of the bootstrapper and would like to apply transforms like can be done for a WiX MSI. And, since the bootstrapper uses the same localization files it'd be nice to be able to use the same approach for the bootstrapper as for an installer.
Many of the things being bootstrapped are MSI based, and you can't really run an MSI from within an MSI install. Bootstrappers are typically executables that contain one or more embedded MSI files - the executable checks if the prerequisite is installed or not, and if not launches the appropriate MSI installs, patches, whatever else is in there.
Related
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'm trying to find out if it is possible to create a burn bootstrapper exe where the chain bundle references non-existent msi packages. In this scenario I'll be using the compressed="no" attribute so the set of msi packages I want installing will not be embedded but will be alongside the bootstrapper.exe
However at the time of compiling the bootstrapper.exe the msi packages to be installed do not yet exist - However they will do at a later date...
The msi packages have well known names that won't change, and will live in a well known location relative to the bootstrapper.exe - they just arent available at compilation time.
Does anyone know if this is possible with wix burn?
Thanks
As far as I know it is impossible - but - you may use some "placeholder" msi files - just for sake of compilation.
Of course if you do so- the data that the bootstrapper builds-up - like the msi installation sizes, the msi file sizes, the feature lists and so on will not ba avialable...
My build system creates a MSI using Wix, it then uses WIX to bundle that into another EXE that acts as a bootstrapper. The bootstrapper makes sure all the dependencies are installed (.NET and so forth).
I would like to change some properties inside the MSI depending on who downloads it. I won't know the settings until long after the build is complete.
I am able to do that with the MSI by editing the properties DB. However when I try the same technique with the bundle, it (WIX interop libarary) says it can't open the file.
So, how can I do one of these things:
Edit a property inside the WIX bundle EXE (that I can then pass to the bundled package)
Extract and re-insert the bundled MSI
You can pass properties using commandline to wix bundle. The bundle then can pass the property to MSI.
WiX Bootstrapper: How do I set burn variables from the command line?
Pass parameters from bootstrapper to msi bundle package
The other solution I can think of: If you write your own custom bootstrapper, you'll have access to IBootstrapperEngine::SetVariable, and you can do whatever you want with that, including setting properties that MSI can read. https://wixwpf.codeplex.com/ should be pretty easy.
If you are asking if there is such tool like orca.exe for Wix burn, then I would say no.
Potential options:
Generate wix burn installer on the fly (including compilation)
Split up executable: set the Compressed attribute to "no". You'll have access to *.msi then.
I have a working wix bootstrapper, chaining two wix msi installers, and it works fine.
The output file of the bootstrapper is an exe file, I am interested in changing the output file to be an MSI file, is it possible with bootstrapper?
If so, how do i achieve this?
Thanks.
No, it's not possible. Bootstrappers have to be executables, not MSI packages. If you want to write your own bootstrapper from scratch, you could use EmbeddedChainer to create an .msi with a chainer inside it, on Windows Installer 4.5 and later.
I created one msi for my product it's working well but I need to install .net 4.0 as a prerequisite. I came across burn and bootstrapper but have a couple of questions:
Should I have a separate project for the main msi and the bootstrapper?
My customer needs an msi (not an exe), so can the bootstrapper be an msi?
The bootstrapper project is a separate project and produces an .exe as its output. It is its own executable, whereas an .msi is essentially a database that gets processed by Windows Installer.
MSI (Windows Installer) does not support "nested" installs, where one .msi package runs for a while, then pauses, runs a separate installer package, then picks up from where it paused. MSI uses some Windows resources that are essentially system-global, so the "inner" install tromps on the "outer" one.
The way to do multiple installs as a single user experience is to run each install in sequence, one at a time. That is the purpose of the bootstrapper, also known as a chainer: to run the chain of installs, link by link. The bootstrapper is not itself an install package; it is a tool for running one or more install packages.
That is why the bootstrapper cannot be an .msi: it is not itself an installer package. A bootstrapper can be as simple as a batch file or script, or you can use an industrial-strength tool such as a WiX burn bundle, Flexera AdminStudio, etc.
Be aware that there are some installer packages that ship as .exe -- for examples, the .NET Framework or SQL Server installers. These are essentially self-extracting archives that contain one or more .msi packages, dump a temporary copy of that payload then run the Windows Installer service on it. In some sense they are "bootstrappers" plus package, all rolled into one. A bootstrapper can run packages (and other bootstrappers), but not vice-versa.
You might think that you could have your outer package run a custom action that launches the inner package. We've all tried it... and found out the hard way that it doesn't work generally, even when you appear to get away with it on some specific target system.
You'll have to persuade your customer that Windows Installer does not, cannot, work the way he thinks it does. Sadly, sometimes the only way to do this is to replace the customer.