Preserve install type when upgrading from per-user

[clive_bor]

Hi,

Our installation used to be of per-user install type, but we are required to move to per-machine install type for deployment purposes since we cannot target a specific user on the machine during deployment.

The problem is that we have existing customers that have rolled out the per-user installations and after releasing our new version they will need to be able to upgrade. We are happy that these upgrades maintain the per-user install type but new installations target per-machine.

I have attempted to do this by using the predefined "Preserve Install Type of the old version" custom action in an example project that simulates our product installation, but it does not seem to be working, both versions seem to be merged in the installation location and both are visible under Add & Remove programs.

I see the following in the installation log:

MSI (c) (F4:EC) [09:36:39:912]: Doing action: PreserveInstallType
Action 09:36:39: PreserveInstallType.
Action start 09:36:39: PreserveInstallType.
MSI (c) (F4:DC) [09:36:39:918]: Invoking remote custom action. DLL: C:\Users\CliveB\AppData\Local\Temp\MSI60D1.tmp, Entrypoint: PreserveInstallType
MSI (c) (F4!40) [09:36:39:924]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.
Action ended 09:36:39: PreserveInstallType. Return value 1.

Attached please find example project files and installation log.

Your help is much appreciated.
Thank you

[clive_bor]

I have also tried using the predefined custom action "Uninstall previous versions" as this would also serve our purpose too, but as stated in your documentation it doesn't work when not used in sequence with the wizard dialog UI and we require the installation to run in silent (/qn) mode for automated deployment.

Is there any workaround you know of to achieve this?
We either need to uninstall the current per-user install with the per-machine install or maintain the per-user install type if already installed.

Thank you!

[Eusebiu]

Hi,

In order to achieve what you want you can follow the steps below in your upgraded project:
- add the "Preserve Install Type of the old version" custom action
- right-click on the "Wizard Dialogs Stage -> Searches" and check the "Show Standard Actions -> Searches -> FindRelatedProducts" action, then do the same thing in the "Install Execution Stage"
- move the "Preserve Install Type of the old version" custom action above the "FindRelatedProducts" standard action
- keep pressed the "Shift" keyboard button and drag-and-drop the "Preserve Install Type of the old version" custom action above the "Install Execution Stage -> FindRelatedProducts" standard action
- select the custom action that you've just moved in the "Install Execution Stage", click on the "Advanced execution scenarios" link and check the "Skip action in Install Execution Stage if executed in Dialogs Stage" option
- build and run the project

In this case you don't need the "Uninstall previous versions" custom action.

Let us know if this helped, otherwise give us more details about your scenario.

Best regards,
Eusebiu

[clive_bor]

Hi Eusebiu,

Thank you for that solution, it works for us when running manually on the machine with the same user that was previously installed as per-user install type.

But we are required to deploy the installation, and this is where the problem comes in; if user "Bob" has version 1.0 per-user install, and we deploy (we use psexec) version 1.1 per-machine install and execute the installation with domain admin credentials, the installation remains and installs as a per machine install and the 2 installations are basically merged for user Bob; like the initial problem.

This is why I was looking at the other solution to uninstall the previous per-user install; since as I understand it will uninstall the per-user installation for another user, but I know msiexec only allows 1 installation at a time so it is a challenge for us to get this working with deployment and a silent installation.

I believe it would be possible to do this using an EXE bootstrap installation, but this would require significant work from our side to cater for the change (MSI to EXE etc.) of the installation package.

Is there any other possible solutions to cater for the scenario explained above?

Thank you for the help!
Clive

[Eusebiu]

Hi Clive,

Please keep in mind that this is the normal behavior. When version 1.1 of the application is installed by an administrator user, it only check if an older version is installed for that user, not for each user on the machine (like "Bob").

If it founds an older version of the product on that administrator account installed as per-user, it uninstalls the older version and installs the new one also per-user, otherwise it installs the new version per-machine, but do not uninstalls other versions of the product that are installed for other users.

I'm afraid that we don't have an workaround for this.

Best regards,
Eusebiu

[clive_bor]

Hi Eusebiu,

Yes I understand. But obviously the problem with this is that Bob's installation of version 1.0 is merged with Administrators installation of version 1.1 since the installation directories are the same and this could cause unexpected failures within the application since different library versions could have been overritten etc.

I'm sorry to hear there is no workaround for this, because it is critical for us to get working.

If you think of anything that we could have possibly missed, please let me know.

Thank you!
Clive

[Eusebiu]

Hi again Clive,

By default, when you go in the Install Parameters page and select the "Per-user only" option the "Application Folder" is set to "[AppDataFolder][Manufacturer]\[ProductName]" path which is different from "[ProgramFilesFolder][Manufacturer]\[ProductName]" path that is set when the "Per-machine only" option is chosen.

So, a workaround for you would be to install your new version at a different location from the previous one (i.e. [ProgramFilesFolder][Manufacturer]\[ProductName][ProductVersion]). In this case the 2 installation will not be merged anymore.

Best regards,
Eusebiu

[clive_bor]

Yes I am aware that selecting the per-user only option defaults to the [AppDataFolder], but we have a legacy issue here where the older per-user version of our product installed to [ProgramFilesFolder]; which we built with AI 6.4 or even earlier version; which didn't select the [AppDataFolder] on selecting a per-user install by default.

We could maybe use the product version with the product name; like the default [ProgramFilesFolder][Manufacturer]\[ProductName][ProductVersion], but we backup and restore files as well is set certain components (mainly ini files for application settings) to "Permanent" to retain them on upgrade.

Would these still work? Since the upgrade normally selects the same directory as the currently installed version..

Kind regards,
Clive

[Eusebiu]

Hi Clive,

CASE 1: If the new version of the product is installed for other user account than the old version, it will not find the the old version and also, it will not select the same directory for the installation (it will be installed to the path you wrote in the Install Parameters page).

However, as you said, the files you want to keep from the old version will not be restored for this new version, but you can achieve this by following the steps below:
- go in the Files and Folders page and create a "Property-based" folder and set for it the path to the old version of your product (name it for example OLD_VERSION)
- create "File Copy Operations" for the files that you want to restore and set the "OLD_VERSION" folder as the source folder for these files
- go in the Searches page and create a "File Search" to search for one of the files that you want to restore (you can rename the search property: OLD_EXISTS)
- go in the Organization page, move the files that you want to restore in the same component and use the search property as a condition for that component (i.e. NOT OLD_EXISTS)
- build and run the project

So, if an old file is found on the machine it means that the old version of the product in already installed. In this case the files you want to restore will be copied in the new version and the same files contained by the new version will not be installed anymore. Else, if the old files are not found, the new version will install its own files.

CASE 2: If the new version is installed for the same user account it will find the old version, it will uninstall it and it will backup and restore your files during upgrade (I think that this is exactly what you want). Although, you can go in the Upgrades page and uncheck the "Use original installation path when upgrading" option, if you wish.

Let us know if you have any other question.

Best regards,
Eusebiu

[clive_bor]

Hi Eusebiu,

Thank you for those possible solutions, the problem we have with that is our application has a service that runs in order to execute tasks that require administrative rights. In Case 1, that would mean that two versions are effectively installed on that machine, and hence 2 services, firstly I'm not sure if the installation of the service the second time will even work and secondly even if the service will install, our application uses RMI to communicate to the service and the second service would fail to start since the first has already bound to the ports used for RMI.

So effectively we require only one version to be installed for a machine, this worked in the past with the per-user install since it shared the service installation and only installed shortcuts and user specific elements for the additional users.

Kind regards,
Clive

[Eusebiu]

Hi Clive,

In order to go around this problem you can try to go in the Service page, select the "Control Operation" you created for your service and enable all three actions on install (Start, Stop, Delete) and see if the old version of your service is removed and the new one is installed when the application is installed.

If all three options are checked, the existing service will be stopped and removed and the service in the package will be installed and started.

Best regards,
Eusebiu

[clive_bor]

Hi Eusebiu,

I understand that this would allow the new per-machine version to be installed and its service will be installed and used, but it would effectively not upgrade the per-user version that was previously installed. So I am not sure what will happen for that user, since he will have the older per-user and the new per-machine version installed.

This would pose a problem to the running state of our application, because we should only have a single instance of it running. Our application starts up when the user logs in, it uses a database in the users application data folder; which can only have a single connection to it, so practically these solutions will not work for our application.
Sorry I should have disclosed the architecture of our application earlier.

What I need to get working (as previously discussed) is to either upgrade the per-user install with the per-machine install (by maintaining the install type; but this didn't work for different users), or uninstall the per-user install for any user on the machine when installing the per-machine install as an admin user when installing silently (/qn for deployment purposes).

I don't think we have the option to have both versions installed.

Kindly please advise, since this is very critical for us to get working to release our next version.
Thank you
Clive

[Eusebiu]

Hi Clive,

As I've already mentioned, it is not possible for a user to uninstall another user's application that is installed per-user. So, when your application is installed per-machine it cannot uninstall the older version of the application that is installed per-user for another user account.

An workaround that I can think of, is to integrate a custom action in your application that will search for an older version and will uninstall it (if it exists) when it is launched for the first time. So, when the user logs on and the application starts up it search for an older version and if it is found, informs the user that the older version must be uninstalled.

Best regards,
Eusebiu

[clive_bor]

Hi Eusebiu,

Ok, we are going to try implement one of these workarounds.

Thank you for your help!
Kind regards,
Clive

[Eusebiu]

You're welcome Clive. Glad to help.

Best Regards,
Eusebiu