0
votes

This is my install execute sequence:

 <InstallExecuteSequence>
            <Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
            <Custom Action='NoDowngrade' After='FindRelatedProducts'>NEWERFOUND</Custom>

            <Custom Action="SetInstallParameters" Before="actionInstall"/>
            <Custom Action="SetUninstallParameters" Before="RemoveFiles">Installed AND NOT REINSTALL AND NOT UPGRADINGPRODUCTCODE</Custom>
            <Custom Action="actionInstall" Before="InstallFinalize">NOT Installed AND NOT UPGRADINGPRODUCTCODE</Custom>
            <Custom Action="actionUninstall" After="SetUninstallParameters">Installed AND NOT REINSTALL AND NOT UPGRADINGPRODUCTCODE</Custom>
      <Custom Action="LaunchBrowser" After="InstallFinalize">NOT Installed</Custom>
        </InstallExecuteSequence>

So I need to implement major upgrade functionality. Custom action called "actionInstall" is responsible for registering MySQL exe as service and runnig application, that performs all neccesary database updates by connecting to it and executing some sql scripts included in my installer.

"actionUninstall" is responsible for unregistering mysql service. Currently I have no any support for upgrading.

I need to implement major upgrade. So while upgrading I need to perform following operations:

  • copy and replace all installer files, except MySQL binaries (MySQL is treated as to be never changed). All files should be copied to program directory, that was used previously (it can be non standard), without any user confirmation.

  • Don't execute SetInstallParameters, actionInstall, SetUninstallParameters and actionUninstall. Instead, I will create another custom action for upgrade only. It will ony execute app to perform database upgrade

  • Don't display any setup dialogs (for example, destination directory selection, license agreement dialog).

My problems:

  • It seems, that major upgrade causes also executing Install and Uninstall - how to avoid it?

  • How to exclude some files (MySQL binaries) from copying to destination dir, but only on upgrade (on install they should be copied)

  • How to set destination directory for new files to the same as it was used by previous installation (it can be any directory selected by user on first install), without asking user to choose directory?
1

1 Answers

0
votes

There are a couple of things to point out first:

  1. The uninstall of the old product is not really "in" the major upgrade - it's a consequence of the major upgrade calling the uninstall of the old product that is already on the system. You can't prevent that uninstall happening because it is embedded in the older installed product and it will happen in a major upgrade.

  2. A major upgrade is not a patch, or update as you seem to be trying to make it. It is a complete new product that replaces the old product entirely. It's an entire product that is available to new clients that happens to replace older products as part of installing the entire brand new product. This comment is really related to your remarks about not replacing the SQL stuff.

So you may not need to implement major upgrade capability unless you change the requirement about the SQL things. For example, if you simply wanted to update some files without doing uninstalls, then you could build an entire MSI file of the same Product, changing only the files you wish to update and incrementing the ProductVersion, a minor upgrade to install with msiexec /i ... REINSTALL=ALL REINSTALLMODE=vomus and there will be no uninstall of the older product - you've done an in-place update. But I don't think you need that.

Note your conditions on the custom actions! They already won't be called on a major upgrade (because of UPGRADINGPRODUCTCODE) or a minor upgrade (because of REINSTALL), so it's not clear to me why you're worried that they will be called during major upgrade. The designer of these calls anticipated this issue.

In your position I'd do this as a major upgrade:

  1. Include the same SQL files as previously. If the binaries are the same they won't be replaced, or the same ones will be there afterwards, so why is there a problem? The install also works as a fresh install for new customers.
  2. The custom actions in the old product being uninstalled won't run because of UPGRADINGPRODUCTCODE in the condition.
  3. The same custom actions in the new product will run during the install, and I assume you don't want that because they will clobber the existing DB. In a WiX major upgrade, use a not WIX_UPGRADE_DETECTED condition (as well as the others) to prevent CAs from running on its install.
  4. If you want to change or suppress dialogs because it's a major upgrade, then use WIX_UPGRADE_DETECTED to alter the flow or suppress them. Don't delete them because, again, you're doing a major upgrade not a "patch".
  5. If you want to install to the same location, it's sometimes useful to write that install location to the registry with the WiX remember property pattern in the older install so you can recover it later. I susperct you didn't test major upgrades before you shipped the product, so you'll need something else. Find a component Id that's in the directory you want to use, then use a WiX Component search to initialize a property that is the directory name.

For the future, make sure that your CA conditions allow a straight uninstall to work properly, and a major upgrade is essentially the same as a fresh install, and replacing or updating binaries doesn't really matter, so make sure new cuatomers can use it. Also, if you need to remember the install location of data files then your design may be incorrect and I suspect your data is in the user-browseable Application Folder. Data should be in a data folder (such as AppDataFolder) so you don't need to worry about its location on an upgrade AND to help enable limited users to run your app because they cannot update files in the Program Files directory.