We've used wix to create our installer for some time now, but previously we've relied on our customer installing SQL themselves.
I now want to include SQLLocalDB for our smaller customers as an option in our installer, but I don't know the correct way to implement this.
I've added radio buttons to our product to chose between using SQLLocalDB or an external server but how do I pass this variable to the bundle's InstallCondition for SQLLocalDB. I Tried using the registry in between but the registry is read as soon as the bundle msi is started and not after the first package has been installed.
My first idea when I started implementing this was to install SQLLocalDB, create the database and the tables from a custom action, but I've now realized that isn't possible
So to finalize my questions:
How do I add optional features correctly?
If I want to create the database and create/update the tables, do I have to create yet another msi for this and add it as a third package in the bundle?
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.
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 am using Wix 3.8
I want to have a single installer UI which will present four applications.Based on user selection
the particular application has to be installed/ uninstalled /upgraded.
So I added four msis in a custom bootstrapper bundle. In the Custom UI we show all four application names
and based on the user selection I set bundle variable value. Install condition attribute is set to this bundle variable.
Also based on the user selection package list will be updated to have only the relevant package(s) .
In this way install is working fine. Install add only the bundle entry in the Add /Remove Programs; and not individual entry for each msi.
I am also able to manage uninstalling a package based on the user selection.
The issue is while uninstalling one msi package it removes the entry of the bundle from Add/Remove Programs list.
Now how do I uninstall other packages?
The behavior what I need is I want to retain the bundle entry in the Add/remove Programs list ; Once the last package is also uninstalled I want to remove the
entry from Add /Remove Programs List. Please advice me how to achieve this?
I'm going to suggest a different way to approach this problem because it seems to me, and I may be way off base here, that you are implementing something using a bootstrapper when you may only need a single MSI that uses a FeatureTree.
A feature tree can list various categories of things to install or not install. For example, it might ask if you want to install:
Framework only?
Framework and Tools?
Only Tools?
And if the user chooses Only Tools and later decides they want Framework, they can go to Programs and Features, click Change and then they'll be able to select the Framework feature from the Feature Tree.
And if they want to uninstall one thing or everything all together, they can do that too.
If you have control over the four MSIs that you mention, you could change them to be Wix Library projects instead. That would allow you to keep developing them separately, by different teams, but have them all referenced in one MSI project.
Orca clearly showing Custom action type 23 - Nested Installation
Inspecting in Visual Studio shows no custom actions at all...
As part of an update on the MSI I'm working on, one of the tasks is to remove the nested installation, as it is a deprecated method.
I can't seem to find where this SQL2000.msi is coming from
I can't find a way to remove it
Any time I build the MSI the custom actions will be there. It's not good enough to edit the MSI after it has been built, it must be built correctly initially.
What possible ways could the MSI be pulling SQL2000 into the MSI?
I can't seem to find it anywhere on my computer.
You should say what is (or was) being used to build this install because it's not clear where Visual Studio setup projects are involved (your custom action view). To my knowledge, Visual Studio has never generated type 23 custom actions. So if you are using a VS setup project to build this project, then the only place it can come from is a merge module, so it should be in the imported merge modules. It's probably an MSDE merge module.
The screenshot of Orca and the custom actions has the format that shows they are from a merge module - the custom action name and then the merge module package code, so the MSM you're looking for is the one with packagecode starting A95D...
I would like to create a installer (like BootStarper) to achieve following steps using WiX.
There will be a setup.exe file.
Upon Runnig this file it has to open a UI and show the list of softwares (MSI) available for installation.
The software products are grouped into two Group A or Group B.
Each group may contain Two or more MSI files (Both internal and third party files)
Allow user to Choose a group and one or more products to be installed.
Based on the selection, the products should be silently installed on the local system.
Shall I create a WiX project and display given products(MSI) as its features and can start a deffered custom action to install the seleted ones?
How to author my WiX project to choose the groups and then selected features?
Any help would be greatly appreciated.
Upgrade to WiX 3.6 (Beta) and take a look at the new "Burn" functionality.
You cannot use a deferred custom action to install another MSI because there is a mutex that enforces one running execute sequence per machine.
There is functionality in MSI 4.5 called multi-package transactions however MSI 4.5 may not be already installed on a 2003/XP/Vista Machine so you'd need setup.exe to boostrap it anyways.
Also "concurrent" installs are deprecated and should not be used to do servicing issues.
This is not something you can solve either with the stable WiX release, or Windows Installer.
You will need a separate bootstrapper to launch your MSI files. as the WiX bootstrapper, Burn is only in the WiX 3.6 beta release and not yet properly documented I would suggest trying something like dotNetInstaller.