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.
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 have an existing large WiX install that has already been released. I need to create a small install for just a couple of files that have changed. I have created a patch (.MSP file) in WiX for these few files using the "PatchCreation" element. When the patch is run, it presents the user with a "Reinstall/Repair/Remove" dialog. If the user selects repair, the patch does exactly what it is supposed to. My problem here is that I don't want the patch to say "repair," or to give the user these options. I just want it to install over the few files I have, more or less like a regular install. What can I do to fix this?
MSI implements patches as repairs. In WiX v3.5, the WixUI dialog library has dialogs that are displayed when installing patches.
I have found a more flexible way to work around this, thanks to some help I found here. If you start MSIExec with command-line options (for example, "msiexec /p [patch file] REINSTALL=ALL REINSTALLMODE=omus"), you can get the install to start up without the "Repair" option coming up. You can also use the IExpress tool (which is shipped with Windows, and can be brought up in a command-prompt) to create a wrapper/bootstrapper that will start the MSP file from MSIExec.
Thanks very much to the answers I received. I would not have figured this out without your help.
I partially agree with Bob. Patches in WiX are applied through a repair, but Windows Installer does support a standalone patch installation. Other setup authoring tools can create them.
Regarding the WiX patch, I recommend using a custom bootstrapper which applies the patch automatically.
Has anyone been able to get Windows Installer to use the InstallUISequence table during removal?
I started with an MSI file produced by the Visual Studio msi builder, decompiled it into WiX source code and handcrafted it, but I cannot get the installer to use my UI during removal. It insists on using a default UI provided by Windows Installer.
I have also analyzed several MSI files, and I have been unable to find one where Windows Installer will use the provided UI during removal.
I captured the msiexec logs during removal, and sure enough, Windows Installer appears to be ignoring the InstallUISequence table.
It seems that msiexec runs with minimal UI during removal. If I specify the /qf switch (use full UI) during removal, then Windows Installer does take the UI from the .msi file. However, this doesn't help the regular user, because she won't do the removal from msiexec.
Does anyone know of a way to convince Windows Installer to use the UI in the MSI file by default?
When removing an application from Add/Remove Programs, this will always run with "basic" UI.
You can't make uninstall run with full UI, the best you can do is prevent removal and force people to 'modify' (which does run with UI) and remove from there.
Whatever you do, there's still no way to prevent someone right clicking on the original MSI and selecting 'Remove', this will always run with basic UI.
The "Why" is basically because Microsoft says so. :-) Can't say I disagree as I get annoyed when ISV's get all cute when I'm just trying to remove a program.
I'm looking for a tool (preferably not InstallShield, and also preferably cheap/Free) that supports Chained MSI Installations. I've got several small installations that need to be able to be deployed separately, but also as one group, and I'd like to not have to maintain multiple installers.
It looks like I need Windows Installer 4.5 to do this properly, but I can't seem to find to much info when I'm looking around for what version of Installer is supported.
The MSI 4.5 functionality is just a set of APIs that allow bootstrapper/chainers to do smarter things for multiple MSIs. You still need a bootstrapper/chainer to install multiple packages. In WiX v3.6 there will Burn.
Incidentally, it used to be possible--although not particularly easy--to "nest" or embed other MSIs into one parent, but it involved tweaking custom actions and such to ensure that the nested programs were removed upon removal of the parent, etc. Sadly, this feature is "deprecated" and thus no longer recommended by Microsoft. Here's how to do it in a Visual Studio installer project... but creating a bootstrapper with WiX would be more advised.
What you need is a bootstrapper. Using and InstallShield or Wix will created an MSI themselves which when that is running will not allow the other smaller MSIs to run. If you already have the smaller MSIs to run a bootstrapper is all you need.
MSDN has a free one you can download that plugs into VS2008 and uses MSBuild to compile. What you will probably need to do is create packages for your MSIs and put them in the bootstrapper as prerequisites. This will allow you to set it up to run them in a particular order.
Here is the MSDN link: MSDN Bootstrapper Manifest Generator
Look at NSIS
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.