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.
Related
We use InstallShield InstallScript projects to create our installers and are looking for a good way to migrate to the WiX Toolset. As far as I know there is no UpgradeCode (as for MSI) to update from an Installshield InstallScript project to a WiX project.
The only solution I found so far is:
manually save configurations
uninstall the InstallScript installation completely
install the WiX installation
apply the saved configurations
Is there a better way?
Ok after all those comments I think I understand why this is such an issue. Unfortunately I don't think there is a very simple way to do waht you want to do.
I think your method will be the only real way to migrate from this isntallscript setup based installation. There should be some registry entry in HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall that relates to your product. In here there may be a uninstall command which you could read into a Variable from your burn package and pass that value as a property to your msi.
In you MSI you can have 3 custom actions specifically related to upgrading from the installshield product installation. All these tasks should be deferred custom actions so that they can run with administrator elevation. The first task should copy all the configuration settings to a safe place (generally %temp%\ProductConfig\ would be fine). The second part after saving the configuration would run that uninstall command to remove the product, you may need to append /q or something to make it run passively/quietly. Then at the end of the installation you can copy back the configuration files from temp.
Each of the custom actions should run conditionally on whether or not the property you passed in is set to something. I would schedule the copy cofig after InstallInitialize, the uninstall after the copy and the restore before InstallFinalize just to ensure that everything is copied over after the installer puts all the files on the system.
Ideally you would like to get everything to upgrade without the user needing to interact except in a minimal way by clicking next and Install.
I've only dealt with InstallShield enough to know I really don't like it so if someone else knows more and knows of a better way to do it they'll hopefully chime in.
I'm struggling with my Custom Bootstrapper Upgrade issue. By following this thread, I'm using LaunchAction.Install.
This does Upgrade the Product as well as Boostrapper, but older Bootstrapper remains there, as shown in following screen shot.
If I invoke ver 1.0.0.0 from here, it would display Dialog to Install, but would do nothing. However, invoking ver 1.0.1.0 would give me the option to Uninstall the product. However, upon Uninstall, it would only remove itself, and "My Product" is left behind.
I also tried with
_bootstrapper.Engine.Plan(LaunchAction.UpdateReplace);
and
_bootstrapper.Engine.Plan(LaunchAction.UpdateReplaceEmbedded);
but it has no effect.
Question: How to upgrade older installation without falling in above situation? Can anyone please provide a working example of CustomBA upgrade?
Regards
Check the PlanRelatedBundle event. Its where you can tell the Engine what to do with the old bundles.
If you want a Bundle to replace the old one the UpgradeCode should be the same for both. In this case it will uninstall the old bundle as default.
Also the old bundle needs to support quiet uninstallation since it will be called with the argument /quit after installing the new one.
You can check it in the BootstrapperApplication.Command.Display property. It should be "Embedded" if its called from another Bundle. The BootstrapperApplication.Command.Action is set to "Uninstall" in this case.
If nothing of this works check the logs that are created in the AppData\Temp folder.
I also experienced this problem. I had to write my own managed bootstrap application. I had a bug where I was kicking off the Plan() phase before the Detect() phase finished.
Hence the old bundle was not uninstalling as it should have.
It is good practice to implement a handler for every event that the Bootstrapper offers. Write a log entry in every handler listing out the arguments supplied to the handler. It makes chasing down errors a lot easier.
In my case I was migrating from InstallShield 2009 to WiX 3.10 and I had to write my own managed bootstrapper because I had to conditionally install SQL Server express based on user inputs from a fancy WPF boostrapper.
I am trying to make my Wix Burn installer install two applications that use NSIS for their installer. Install works great. However, I want them to be removed when I uninstall my app (Permanent="no"). This is not so straightforward as I cannot call a different exe (the uninstall.exe that is created) from the UninstallCommand property on he ExePackage. Is there another way? Is there a simple command line argument that an NSIS installer can take to uninstall?
You would have to request the author of those installers to add support for that, NSIS does not support it by default.
I don't even think it makes any sense for installers to support it:
The same program could be installed multiple times on the same machine (single user and all users?, multiple versions?)
What if the installer does not write to the registry, how is it even supposed to find the original install?
Not what I would call a perfect answer, but a functional one, so I thought I'd share. Save someone providing a better option, I am creating custom actions to handle the uninstall. NSIS is consistent (by default, anyway) in their uninstall policy. Knowing what that is, I can plan for it. Messy, for sure, but seems sound.
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.
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.