1

Having an issue with WIX installer upgrade. Previously we had 2 version of installers 1 for per-machine and another for per-user.

Currently we have developed a dual mode MSI.

The dual mode MSI upgrades the PerUser version (on PC 1) of previous installer when install for yourself option is selected but when install for all (on PC 2 ) is selected it install a new product

Is it some wrong that we are doing or is have to set some properties. We are using WIX.

Please help

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Mohtashim
  • 216
  • 2
  • 8

4 Answers4

2

Per-user installs allow the installation of the same product multiple times for different users - and in different versions too. This makes upgrades and patches rather difficult to deal with, and I dislike this per-user concept altogether. I prefer to set the installer per-machine as standard. I don't feel that much is lost in functionality, but a lot is gained in managability. Though this is not an answer to your question, it is worth pointing out that per-user installs is a flawed concept - at best.

I don't know if it is an option to set your installer per-machine, but I found a way to migrate installs from per-user to per-machine automagically by using Installshield and its custom ISSetAllUsers custom action. The procedure is described here: windows Installer - uninstalling previous version when the versions differ in installation policy (per-user, per-machine)

Wix does not feature such a custom action as far as I know, but you could write your own custom action using the Win32 API call ::MsiEnumRelatedProducts() as described by Rob Mensching here: how to change from per user to all user installation?

Here is a similar post for reference: How can a perUser installation program deal with a perMachine older version of the program?

Here is a blog describing (further) issues with per-user installs: Understanding “Per-User” or “Per-Machine” context for application Setup packages.

Let me add a couple of further comments:

  • You can have per-user settings without a per-user install. This is no problem, just have the application set up the userprofile on launch. I prefer to install all resource files and settings per-machine and have the application copy them to each user for first launch initialization. This ensures that user settings are not entangled with your MSI at all.
  • It is rare to maintain two separate versions of the same product at the same time - hence users are all likely to use the same version of the product. Per-user is just more headache in this perspective.
  • The upgrade and patching logic involved in per-user installer scenarios beats me - it just doesn't make any sense to me. If there is a per-machine install already, does a per-user install make sense to you? Does this install the application one more time?
  • If per-user installs are still important, perhaps you can try ClickOnce (if it still works). Quote from Wikipedia: "...ClickOnce-deployed applications are considered 'low impact', in that they are installed per-user, not per-machine. No administrator privileges are required to install one of these applications. Each ClickOnce application is isolated from the others. This means one ClickOnce application is not able to 'break' another.". Per-user installs make more sense if they are hooked up to auto-updating and web-deployment.
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thank you stein for information. I agree our installation is a maintenance nightmare. Could you tell me why is our installer is performing a new per-machine install without upgrading the existing per-machine – Mohtashim Apr 24 '15 at 09:38
  • Have you tried to run your installer with detailed log? msiexec /l*v log.txt... You may find the reason there, written in plain English :) – Nikolay Apr 24 '15 at 20:55
  • It is not a flawed concept. Different users should be able to have different apps installed and moving forward this should be the default. If two users run two instances of the same app and one decides to uninstall it, the other user should still have access to it. This is how the Windows Store works for example and makes perfect sense. – MoonStom Jan 27 '20 at 20:20
  • Per-user installations are fine for many things, but not for all purposes. In corporate environments they might be good for small applications, but we lack - currently - the proper tools to handle all the fallout of the maintenance issues that result (uninstall, patching, etc...) and we see anti-patterns in management of user data. Among other problems. Settings management is strictly speaking a larger issue of application design and potentially clouding of settings properly to counter deployment issues with user data, but that is another discussion - though related to per-user deployment. – Stein Åsmul Jan 27 '20 at 21:08
1

I believe this is occurring because in your installer the default mode is Per-User hence it is not detecting per-machine. You could use MSIGetProductInfo to find the installed products if the assignmenttype is “1” then you could set the below properties to Product Code of Per-Machine product WIX_UPGRADE_DETECTED OLDERVERSIONBEINGUPGRADED

Use a custom action on button click or schedule it after FindRelatedProducts. This tells the installer of an existing version and installation is handle like an upgrade.

Piyush
  • 11
  • 1
  • Thanks piyush. I took your suggestion to look for per-machine installs and if found i am assigning the product code to the Properties mentioned. And as expected during upgrade our new per-machine installer is upgrading the older per-machine installation. Thanks. – Mohtashim Apr 27 '15 at 06:04
1

Windows Installer does not upgrade between per user and per machine, or vice versa. If you want this to happen you need to get in front of the install somehow and find out what type is already installed. Trying to do that when the product has been installed for another user (i.e. not the current installing user) is tricky. MsiEnumRelatedProuctsEx can be called a couple of times looking for per machine and per user installs to see what's going on. However there may be issues with you, User A, trying to uninstall a product that was installed per user by User B. If you are the same user it's easier. MsiEnumRelatedProductsEx can be called a couple of times to see if the product is per user or machine (in a launcher maybe) and you can uninstall the product before installing the new upgrade, or at least tell the user to do the uninstall. Anyway, it can be a mess, and the advice to stick with per machine installs is worth taking.

I should also point out that allowing per user AND per machine installs on the same machine is a feature, not a bug.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Like you said phil we have added a alert box after MsiEnumRelatedProuctsEx detects any installations to convey the user of per-user installations and requesting them to uninstall these manually if they want per-machine to be installed. – Mohtashim Apr 27 '15 at 06:00
1

If you had two setups before, it might be that you have two upgrade code and need to deal with both for the upgrade to work in all cases?

It has been a long time since I dealt with per-user stuff, but in general you must author your Upgrade table to include both upgrade codes for your setups to detect all flavours of your previous install. The upgrade table allows you to detect any number of prior installs that should be scheduled for uninstall before your new product gets installed.

The FindRelatedProducts MSI action will search all packages on the target machine in order to find any where the Upgrade Code property matches the value specified in the upgrade table.

Make a verbose log file as has been suggested:

msiexec.exe /I "File.msi" /QN /L*V "C:\Temp\msilog.log"

/I = run installation sequence
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164