2

This is similar to the question asked here: How do I fix the upgrade logic of a wix setup after changing InstallScope to "perMachine"

Only in our case, the old version is "perMachine" and the new version is "perUser".

I understand why you would not want a perUser installation to mess with a program that might be shared among several users. But we need to go down this path.

Currently, we are detecting versions of the old program by digging around in the registry and refusing to install unless they uninstall the old version first. It isn't real user friendly.

Are there any better techniques?

Community
  • 1
  • 1
Steve Wellens
  • 20,506
  • 2
  • 28
  • 69
  • Users can have their own settings even if you install per-machine. What settings are they? Also, you don't dig in the registry to determine what is installed, you use the Upgrade table and implement a major upgrade. Never touch the MSI registry database - it's fragile and complex. – Stein Åsmul Mar 31 '14 at 21:39

2 Answers2

0

It can't. Major Upgrades can't switch context and even if you wrote a setup.exe bootstrapper to clean up before the installation it would have to be run for each user profile that installed the product.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Check the link above - I used it to clean up a special case once, but it is an odd solution to say the least. I too wonder how this affects the MSI database - it seems to re-register the product per machine and unregister a per user install, but does it do so for all users? I don't recall. I think we used this as a one-time fix for systems with primarily one user. – Stein Åsmul Mar 31 '14 at 19:09
  • If user A did the per user install and user B is trying to do the per-machine install, it can't possibly work. – Christopher Painter Mar 31 '14 at 20:50
  • I am thinking it could - it would double up the ref-count on the components, and leave the product registered per-user for some users? Beats me how an upgrade scenario would look though. Per-user installation is a no-no in my world. Just trouble. – Stein Åsmul Mar 31 '14 at 20:52
  • Let's say that app had COM or other registry data registered per-user. That would take priority in HKCR over fresher data from the per-machine install in HKLM\SOFTWARE\Classes. There's just a bunch of things that can be ugly wrong. – Christopher Painter Mar 31 '14 at 21:19
  • Always thought per-user installs are conceptually ugly anyway - and yes, I think user COM-data would win in HKCR. Could Active Setup be used to run a per-user uninstall once per user after installing per-machine? Perhaps if you specify the right package code to kill the per-user variant? Maybe, but it would trigger some self-repair I guess. – Stein Åsmul Mar 31 '14 at 21:32
0

I would never change to a per-user setup, I would rather go from per-user to per-machine for an awful lot of reasons. Why do you need per-user?

You might have a look at a description I wrote up on how to migrate to per-machine from per-user using Installshield. Going the other way should be possible too - but not recommended in my opinion: https://stackoverflow.com/a/12291807/129130

UPDATE: Since this was down-voted, here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • The requirements are per user so each user has their own settings. You haven't posted an answer. You've posted a comment. – Steve Wellens Mar 31 '14 at 20:15
  • I have in fact answered several of your questions just now, and you haven't answered any of my follow-up questions :-), and that link is indeed an answer to your question - for Installshield, and the same concept could work in Wix. Which tool are you using? – Stein Åsmul Mar 31 '14 at 20:21
  • And users can have their own settings even if you install per-machine. A per-user install is one of the worst concepts of MSI in my opinion - it merely changes a few directory paths and hides the product from other users. – Stein Åsmul Mar 31 '14 at 20:28
  • 2
    Why would an application need to be installed per-user to have per-user configuration setings? (answer: it wouldn't) – Christopher Painter Mar 31 '14 at 20:48
  • One user's actions should not impact another user's profile. Especially in environments where multiple user accounts run instances of the same app. If a user decided they don't need the app and uninstalls it, the other user should still have access to it. With the proliferation of per-user app stores, this is gonna be the norm moving forward anyway. – MoonStom Jan 27 '20 at 20:13
  • Per-user setups are "in" at the moment. We have seen them before come and go. MSI per-user setups ARE problematic - we are long-term users of MSI and we know. For other deployment technologies - potentially future ones - per-user deployment might be the norm as you say. However, we might not want to deploy "Call of Duty" per user :-). – Stein Åsmul Jan 27 '20 at 20:58
  • Nothing is "in" or "out". Apps are all different. But that's not even the point. You can't make blanket statements like that :) I will ALWAYS downvote answers that question someone's intentions :) Just answer the question if you can. It really is that simple ;) – MoonStom Feb 11 '20 at 23:44
  • Per-user setups might become popular - again - in new incarnations with better implementation, but per-user setups with MSI are very hard to deal with. Nobody's intentions are questioned, but we try to warn people about problems they will face when taking on technologies that have difficult challenges and unexpected bear traps. – Stein Åsmul Feb 12 '20 at 11:37