Hello dear folks at Advanced Installer. We have been a happy customer of your product for about a year, ever since it has helped us solve some rather quite tricky problems, mostly related to updates. While I have been able to solve most of them by reading the Community page and playing around, I am in need of your assistance now.
The problem we are having occurs after an update is performed on a per-user installation, which doesn't require elevated privileges. Even though I have used PreserveInstallType custom action, placed in both Wizards Dialogs and Install Execution stages, the install type does not seem to be properly persisted. Namely, before I added this action I had issues with directiories being changed after an update, paralel installed versions and probably more. After adding the custom action I have none of those and all seemengly works well. However what happens is after the update, uninstallation of the our app requires elevated rights, and by extension all the following updates as well (A rather funny situation as thanks to you our per-machine updates no longer require admin rights)
I have tried adding the PreserveInstallType action before Searches, after Searches, after Searches but before FindRelatedProducts, all with no luck. I will attach our project file both and uninstallation logs before and after an update (for some reason Windows doesn't generate logs for the update). The main difference I believe in the uninstallation logs are these three lines:

PROPERTY CHANGE: Adding MSIINSTALLPERUSER property. It's value is '1'
PROPERTY CHANGE: Adding MSIINTERNALINSTALLEDPERUSER property. It's value is '1'
Determined that existing product (either this product or the product being upgraded with a patch is a dual mode package installer in per-user mode.

Those show up in uninstallation logs before the update but not after. I have yet to go through "bad" update logs for per-user update and "good" for per-machine update, to try to see if I can draw some kind of parallel, but it's probably gonna be hard as I don't have an example of "good" per-user update.

Hello Luke,

This is indeed quite the interesting scenario.

However, in order for me to best assist you here, I would need to run some tests and further investigate this on my end.

That being said, do you think you can create a sample project that reproduces this, together with a test-case, and forward that to me by email at support at advancedinstaller dot com?

Best regards,
Catalin

Hello Catalin,

Thank you for a swift response and for taking an interest in our problem. Could you clarify just a bit more what the sample project would look like?
The thing is I would try to keep the project unchanged, or with only the necessary changes. If I am not mistaken you would only need to remove all the files and folders which are being packed into the installer and replace them with some dummy ones (I believe it is irrelevant what is packed into the installer itself) and use your own certificate for signing it (although I believe it is also not necessary for the installer to be signed in order for the problem to be reproduced.
As for the update itself, I don't think I can give you access to our AWS S3 bucket where we keep the versions and the updater file. Below are the links to the Updater project file and two installers using which the problem can be reproduced. Actually, you only need the Scribe_24.msi to repro it, Scribe_26.msi is the installer for the version on the server.
We have set up a silent update when the user quits our app. So in order to trigger the update you need to install it, run Scribe and quit the app in order to trigger the update. If you go to Settings -> Apps, Scribe_24.msi will install the version 3.2.4 and after the update you should see the 3.2.6 which will have the described problem. Also of course, you can use ScribeAutoupdater.exe, which is just renamed updater.exe program, with the command line parameters for silent update in order to perform the update.

https://drive.google.com/file/d/1Mq08on ... sp=sharing
https://drive.google.com/file/d/1AfnXRt ... sp=sharing

One more thing, we have been trying some thing out and were able to uninstall the problematic installation without the need for admin privileges with msiexec.exe from the Terminal using the MSIINSTALLPERUSER=1 parameter. This of course does not resolve our issue but is maybe one more interesting clue.

If I can assist you in any other way with the repro or anything else I am at your disposal.

Hello Luka,

I apologize for the quite delayed reply.

Could you clarify just a bit more what the sample project would look like?

The simple project(s) would look like this:

- the AIP file that builds the first version

- download link for the first version

- the AIP file that builds the second version

- download link for the second version

The AIP file can be empty if no files are needed in order to reproduce this.

Now, coming back to the files that you provided, I have run a little test and I wasn't quite able to reproduce this on my end.

Here's how I tested it:

- installed version 24

- installed version 26 over (manually, not through the Updater)

- uninstalled version 26 from Control Panel (no UAC was spawned)

Did I miss something here?

Anyway, if you could provide the sample project that would ease the process by a large margin.

Best regards,
Catalin

Hello Catalin,

No problems. Ok, I will send you the mock project first thing Monday. And as for the repro, could you read through my second reply? You should try the trigger the update and then the uninstall. I described two ways in which it can be done. On is just by closing our app, which triggers a silent update once closed and the second is to use the updater process through the command line with parameters for silent update.

Cheers,
Luka

Hello Luka,

Did you manage to send the files?

I had a look over the email and I wasn't able to find the resources.

And as for the repro, could you read through my second reply? You should try the trigger the update and then the uninstall. I described two ways in which it can be done. On is just by closing our app, which triggers a silent update once closed and the second is to use the updater process through the command line with parameters for silent update.

Sure thing, I will give this a try as well.

Best regards,
Catalin

Hello Catalin,

Just sent you the email with resources. Sorry for the delay!

Cheers,
Luka

Hello Luka,

Thank you very much for the provided resources.

After testing this, I was able to reproduce the behavior you have described and also to find the culprit of this.

First of all, please note that the PreserveInstallType custom action is only taken into consideration if you run the setup with Full UI (basically it only succeeds when scheduled in the Wizard Dialogs Stage in the Custom Actions page).

Now, in order to achieve what you want, you've been close with the MSIINSTALLPERUSER property. However, we were missing something there.

If you create a log file for v2, you can notice that the value of the ALLUSERS property is set to 1.

In the ALLUSERS property article, we can notice the following:

If the value of the ALLUSERS property does not equal 2, the Windows Installer ignores the value of the MSIINSTALLPERUSER property.

That being said, although the value of MSIINSTALLPERUSER was "1", which is correct for a per-user installation, this value was ignored due to the ALLUSERS property not being "2".

That being said, the correct command line looks as it follows:
Hope this helps!

Best regards,
Catalin

Hello Catalin,

Thank you for the explanation about the ALLUSERS property. However that is not exactly where the problem lies here. My main issue is that PreserveInstallType is working only partially when the silent install/update is performed. It seems to be working well to detect where the new version should be installed to (same place where the old one is), however it seems to mess up the properties you mentioned somehow.
If I understand correctly what you are saying is that PreserveInstallType is by design not working for silent installations, which seems really strange as it is quite a bit more useful there, when you can not choose the install type, than in the Full UI mode. Also, based on our current experience it is generally working, just not all the way. The behavior is definitely different, and worse, without said custom action.
So, to sum up, if I understood correctly could you just confirm that PreserveInstallType is not intended, by design, to work for silent installations, and if so is there some specific technical reason preventing you from implementing it? Also, if that is the case, is there a reasonable workaround we could implement? I am sure I could get it working by using a certain variable in the registry to save the install type and than read that during the updates, however it just seems like an unnecessary hassle, when we have this custom action which should do exactly that.
Also if you take a look at the screenshot I attached, are you telling me that adding PreserveInstallType to the Install Execution Stage like in the image basically does nothing? I got the idea from one of the responses on this forum. If necessary I could probably dig it out.

Looking forward to your answer,
Luka

Hello Luka,

Although you see some improvements, as you mentioned, this is not the "expected" behavior.

The reason for that is a limitation of Windows Installer (the technology Advanced Installer is built upon).

By default, the installation type is set to "per-machine".

If someone, or something (like our custom action), tries to set it to per-user, it has to do so before the InstallExecuteSequence.

During a silent installation, the installer goes straight to InstallExecuteSequence, so in that case we have to set the installation to per-user prior to that, meaning we have to do so from the command line.

Hope this helps!

Best regards,
Catalin

Hello Catalin,

I understand. For me, the confusion has arisen from this post I found from 12 years ago from who I assume one of your colleagues who describes using PreservedInstallType to solve the same problem I have by placing it in InstallExecuteSequence as well. viewtopic.php?t=25984

Is this something that has worked before and does not anymore or has Eusebiu been wrong?

Also, is there some way of triggering the Wizard Dialogs stage in a hidden way or just briefly in order to accomplish the job PreservedInstallType? Or if not that, what would you propose as a workaround in our case?

Cheers,
Luka

Hello Luka,

I've actually talked to my colleague Eusebiu and he told me that at the time of that post, he was with the company for like 3 months, so the answer is indeed wrong.

Also, is there some way of triggering the Wizard Dialogs stage in a hidden way or just briefly in order to accomplish the job PreservedInstallType? Or if not that, what would you propose as a workaround in our case?

During a silent installation, the only way of doing so would be through the command line as I've mentioned before.

Best regards,
Catalin

Hello Catalin,

Hahaha, ok, fair enough. I understand the pain that the complexity of Windows brings. Thank you for going above and beyond. Say hello to Eusebiu.

Ok, one final question, I hope. There are two ways where I could manage this problem, during the update process or during the uninstallation process. However how could I control and pass the correct parameter to the updater during the updater process? I know how I could hardcode it, but how can I pass the correct one depending on the previous installation? And if not there is there a way in which I could hook into the uninstall sequence from the Windows Settings and pass the command parameter there?

Cheers,
Luka

Hello Luka,

Thank you for going above and beyond. Say hello to Eusebiu.

You are always welcome and sure, I've sent your regards to him.

Now, regarding your question, it is possible to pass the command line by using the "Command line" field from the "Update Installer" tab.

However, it is not possible to conditionally pass a parameter there.

What I'm thinking here to achieve something similar as above is:

- have two updates in place, one with the per-machine and one with the per-user parameters

- under "Update Installed Detection" tab, instead of HKUD use HKCU (for the per-user one) and HKLM (for the per-machine one)

Note: HKUD will check both the per-user and the per-machine hives

So basically, we rely on the following logic:

- if setup was installed per-user --> the used hive will be HKCU --> we use the per-user command lines

- if setup was installed per-machine --> the used hive will be HKLM --> we will use the per-machine command lines

This might not be the most ideal, but it's the only way I can think of to achieve "conditionally passing of arguments" as you currently require.

Hope this helps!

Best regards,
Catalin