0

I have an app with an existing autoupdate mechanism, that includes a fail-safe: if the installation fails, it uses the old .msi file to restore the old version. The update procedure finds the old .msi file in the \Installer directory.

I recently updated installer generation to use WIX. Now, when the app is installed, the .msi file is not copied into the \Installer directory, all that is created is a file called wix{}.SchedServiceConfig.rmi.

I tried perfecting the WIX installer, using its transacted nature, so that if the installation fails, the installation transaction would be rolled back, and the old version restored - but for some reason, most of the time, when the installer fails, I end up with the app being wiped.

I tried finding the .msi file used for the install in other locations, so that the auto-updater can re-run the installer in case of a failure, but I can't find the msi copied anywhere.

Any ideas how a.) an installer created with WIX can be authored to be fully transactional? or b.) where to find the msi after the installation?

balintn
  • 988
  • 1
  • 9
  • 19
  • Auto-update features do not mix well with MSI - in fact they are considered anti-patterns (technologically unsound due to severe error potential). MSI keeps track of all installed files and all versions - updates could trigger [self-repair](https://stackoverflow.com/a/5983973/129130) to overwrite erroneous file-versions if detected on application launch (and there are many other problems). [Please see this previous answer on MSI and other technologies regarding their upgrade features](https://stackoverflow.com/questions/51591399/what-is-the-best-practice-to-auto-upgrade-msi-based-application). – Stein Åsmul Jul 20 '19 at 00:53
  • Maybe MSIX is the way for you to go? Worth a try? [MSIX Summary](https://www.advancedinstaller.com/msix-windows-package.html) and [MSIX Comprehensive Guide](https://www.advancedinstaller.com/msix-introduction.html). – Stein Åsmul Jul 20 '19 at 00:59
  • If an auto-updater just downloads and runs the newest MSI file, which uses Major Upgrade for instance, I don't see what's wrong with that. @Stein propably refers to auto-updaters that directly modify the application directory content, circumventing the MSI inventory. – zett42 Jul 20 '19 at 08:38
  • Transactional behaviour of a [`MajorUpgrade`](https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html) can be controlled through its `Schedule` attribute. Though I've found all options except the default of `afterInstallValidate` to be either unreliable or error-prone in practice (you have to be very very careful about component rules). So I would stick with `afterInstallValidate`, but let the auto-updater keep the package of the last version so it can rollback to that version. – zett42 Jul 20 '19 at 08:52
  • Agree on the auto-update with newest MSI. That is just fine and [is in fact what I write about in the linked answer](https://stackoverflow.com/a/51601083/129130). However I don't think the OP downloads a new MSI, but rather overwrites files on the fly - without an MSI doing so - after original installation and this is very problematic use of the MSI-paradigm (which seeks to have full registration of all installed files and then to keep that registered version installed with [self-repair](https://stackoverflow.com/a/5983973/129130) as one of the mechanisms to ensure correct file version). – Stein Åsmul Jul 20 '19 at 09:09
  • I can offer these links for more technical information: [Why does MSI require the original .msi file to proceed with an uninstall?](https://stackoverflow.com/a/1189524/129130) And here is on: [MSI Caching locations](https://stackoverflow.com/a/48823086/129130). But really: do not overwrite MSI-deployed files! You are fighting windmills. Maybe look for another technology. Here is a: [Quick ad-hoc deployment technology review](https://stackoverflow.com/a/49632260/129130). Not great, better than nothing I hope. – Stein Åsmul Jul 20 '19 at 13:46

0 Answers0