I have written a managed bootstrapper application using WiX toolset's burn API and it works great. Currently it chains 2 MSI packages. Now I need to chain a exe package before the 2 MSIs. This exe package will obtain a value (when it runs) which it needs to pass back to the bootstrapper. Basically, the bootstrapper has a bunch of variables which it uses to populate properties in the 2 MSIs. One of these variables now needs to be updated by the exe package at runtime, so the corresponding MSI property reflects the correct value.
I have looked around and not been able to find anything that indicates that this can even be done. These two links (here and here) speak of similar things, but they all mention that burn variables can be updated at runtime via command-line or within the bootstrapper itself. Not how a ExePackage could pipe back an update to a bundle variable, which is what I need to do.
Would appreciate any feedback.
[UPDATE]
Found a comment by the WiX developer here that points to some sort of communication mechanism between an ExePackage and the bootstrapper.
There's no mechanism to let a package communicate with the Burn engine, other than to indicate success or failure.
Related
We have a burn bootstrapper bundle that installs a bunch of prerequisites, launches our main install, then runs a few extension installers silently. We've recently had to add a couple of new components to the installation bundle, both of which require configuration information that's already gathered from other products launched earlier in the install. So basically:
Package 1 is installed and a UI is presented. It asks for a service user and password.
Package 2 was added to our bundle. It also needs a service user and password, the same as for package 1.
Package 3 was added to our bundle. It also needs a service user and password, the same as for package 1.
We'd like to keep from having to have the user configure the same information three separate times. One possible solution we saw was to write our own WiX bootstrapper application, but that seems fairly heavy handed. Another possibility we considered was perhaps there was a way to have package one call a custom action which sets the value of a burn variable. We could then call packages two and three's installers with the burn variable passed in as part of their silent install commandline. Is there a way to do this? If so, what would it involve?
We did eventually find a solution to this, making use of the extended bootstrapper application from Neil Sleightholm. This allows creation of custom actions in the bootstrapper. We created a WiX burn custom action which in OnDetect launches a separate thread. That thread opens a named pipe and listens for pairs of variable names and values to be sent through: when it gets such a pair, it uses the engine's SetVariableValue command to set the value. In the called install, we created a custom action which connects to the named pipe and sends across variable names and values according to what it gathered. The variables' new values successfully get passed on to subsequent installs, however install conditions are evaluated before any installs are launched, so those cannot make use of variables whose values are set by installs.
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!
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.
Someone asked a very similar question, but the response was unhelpful. It would be extremely valuable if there was a knowledgeable answer...
I have created a WiX project using Windows Installed 4.5. I included an EmbeddedChainer element reference in the wxs file for the MsiEmbeddedChainer Table, which allows multiple-package installation.
<EmbeddedChainer Id="Chainer" FileSource="InstallMSI.exe" />
I looked around the net and finally found a single post that showed how this person retrieved a handle for the internal transaction. Now, my installer correctly calls my executable to process the chained MSIs. However, uninstalling does not work. Please note that without the above EmbeddedChainer element, the uninstall works fine.
I've read all the available document and I cannot find a single example project.
Can anyone provide some guidance in creating a WiX based multi-MSI install package?
The WiX documentation for EmbeddedChainer refers to the MSDN documentation for MsiEmbeddedChainer Table, which in turn directs you to reference Monitoring an Installation using MsiSetExternalUI
Rather than looking for a WiX specific example, I suggest looking for any MSI example. From there it will be fairly easy to figure out where you're going wrong with WiX.
The same embedded chainer executable Main() will be called again when uninstalled. In order for the chainer code to detect whether to install or uninstall, the parent installer should pass the argument to the chainer Main function. When uninstall, the parent installer has the property [REMOVE] set to the either "REMOVE=ALL" or "REMOVE=feature1,feature2". Set the EmbededChainer/#CommandLine to "REMOVE=[REMOVE]" and in the Main of the chainer code, parse the argument list and pass the data to the MsiInstallProduct() as argument. When the MsiInstallProduct() see the argument "REMOVE=ALL", the child MSI will perform the uninstall.
I'm trying to find a solution for the following issue:
I have numerous programs (lets call them slaves) that all rely on a single program (master). I need to distribute an installer for each slave. This installer needs to install the master.
I want to be able to version both pieces, so multiple msi's appear to be the right solution, chained with a bootstrapper.
My problem is if a slave installer installs the same version of the master that is already installed, the .msi will run in repair/remove mode.
This is unacceptable from a user standpoint and will just cause confusion.
Is there any way to check for a version of the currently installed fiels before trying to run the msi?
I am currently using WIX's setupbld.exe as a bootstrapper.
Any other solutions greatly appreciated (I have also tried merge modules with no success, since the versioning is useless)
Instead of using setupbld.exe (which I don't really know as I can't find any documentation) you can use msbuild's generatebootstrapper task. The wix documentation already covers how to use this task to generate a bootstrapper that installs the .NET framework. See How To: Install the .NET Framework Using a Bootstrapper. This makes use of the pre-defined bootstrapper packages.
However, in this case you will also have to author your own bootstrapper packages. One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
To determine whether the package needs to be installed, you can use one of the InstallChecks to set a property, and then check the property value in a InstallCondition under the Commands element.
If you're thinking that this is all harder than it should be — I agree, but it's what I've used so far. There are some alternatives which I have not tried yet:
the poorly named dotNetInstaller
which is actually a general purpose
bootstrapper generator.
the wix 3.5 burn bootstrapper which is not yet released. I'm not sure if it is in a usable state yet.