How to pass properties to removed product's MSI during major upgrade?

[sasha]

Hello,
thanks for looking at this question.

I have the following problem: how can I pass some custom properties to the MSI of a version of a product that is being upgraded?
Normally the values are obtained via user entering them in a custom dialog.
On the upgrade, they can be passed on the msiexec's command line, especially if running in the no-UI mode.

The problem is that with the UI mode, the prompt to enter the value is presented twice - first for the new version of the product, then for the old version - when it is being automatically removed. With the passive mode, the values from the command line are not passed to the old version and it fails to uninstall, because it has no required properties.

I've searched far and wide and so far, was unable to find a way to pass the properties from the new to the old. Is there any? Without this functionality simple automated upgrading of the product will not be possible, and the product may be installed on many thousands of desktops within organizations. Doing the uninstall of the old and then install of the new will result in the loss of configuration data (during upgrade we migrate the data).

Thanks!

[Catalin]

Hello Sasha,

Please note that the uninstall and install operations from an upgrade are basically two separate instances of Windows Installer and if you pass the properties through the command line, they will only be available to the installed MSI, not the uninstalled one as well.

A possible workaround is the one described by my colleague Eusebiu here:

Re: passing installer parameters to uninstaller during upgrade

Hope this helps!

Best regards,
Catalin

[sasha]

Thanks, Catalin. I've seen that thread. Unfortunately, modifying the old installer is not an option.

[Catalin]

Hello Sasha,

I'm afraid I'm not aware of any other solutions to achieve that.

Honestly, I don't think that is achievable.

Best regards,
Catalin

[sasha]

Yeah, that's what I was afraid of
Thanks for your assistance.

[Catalin]

You are always welcome!

If you have any other questions, please let me know and I will gladly assist.

Best regards,
Catalin

[sasha]

Well, it's been almost a year, so good time to revisit this question

In the log file of a new version when trying to upgrade I see this:

MSI (s) (24:B4) [14:58:00:659]: Doing action: _F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C.SetProperty
Action ended 14:58:00: MsiUnpublishAssemblies. Return value 1.
MSI (s) (24:B4) [14:58:00:659]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = '_F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C.SetProperty'
MSI (s) (24:B4) [14:58:00:659]: PROPERTY CHANGE: Adding _F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C property. Its value is 'ADDRESS="" PROXY="" ACCOUNTNAME="" PASSWORD="" PASSWORDHASH="" KEEPLOCALDATA="" DELETELOGDATA="" INSTALLLOC="C:\Program Files\Windows Event Reporting\Install\WERSource-6.2.4018\" UILEVEL="3" INSTALL_CONFIG="1" ALLOW_SSL=""'.
Action start 14:58:00: _F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C.SetProperty.
MSI (s) (24:B4) [14:58:00:659]: Doing action: _F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C
Action ended 14:58:00: _F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C.SetProperty. Return value 1.
MSI (s) (24:B4) [14:58:00:659]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = '_F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C'
Action start 14:58:00: _F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C.
MSI (s) (24:B4) [14:58:00:659]: Doing action: UnpublishComponents

Later on:

MSI (s) (24:B4) [14:58:00:870]: Executing op: ActionStart(Name=_F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C,,)
MSI (s) (24:B4) [14:58:00:870]: Executing op: CustomActionSchedule(Action=_F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C,ActionType=3089,Source=C:\Program Files\Windows Event Reporting\Install\WERSource-6.2.4018\EventReporting.InstallHelper.dll,Target=Uninstall,CustomActionData=ADDRESS="" PROXY="" ACCOUNTNAME="" PASSWORD="" PASSWORDHASH="" KEEPLOCALDATA="" DELETELOGDATA="" INSTALLLOC="C:\Program Files\Windows Event Reporting\Install\WERSource-6.2.4018\" UILEVEL="3" INSTALL_CONFIG="1" ALLOW_SSL="")
MSI (s) (24:20) [14:58:00:870]: Invoking remote custom action. DLL: SomePath\InstallHelper.dll, Entrypoint: Uninstall

The properties ACCOUNTNAME="" PASSWORD="" are what is provided on the command line to the new version of the product. And the new installer knows to pass them on to the old uninstaller!

But for some reason the values of the properties are not passed in.

Here is the part of the command line for the new version:
setup.exe /qb+ ACCOUNTNAME="admin" PASSWORD="pass"

So, does it look like this should work? The properties from the command line of the new version should be passed to the old one?
Thanks!

[Catalin]

Hello Alex,

As previously mentioned, I'm afraid this might not be possible without doing some prior modifications to the uninstalled package.

This is not really something related to our product, but rather to how major upgrades work in Windows Installer.

We basically have two instances of Windows Installer, one for uninstall and one for install. These two are asynchronous, meaning they do not know of each other.

That being said, if you want the values to be passed to the old installer (that is currently uninstalled), we would have to have a "bridge" between the two processes that would allow the uninstall process to read the values. One such "bridge" could be the workaround described by my colleague Eusebiu in the post I've linked above - i.e. in the install process, we write the values as early as possible in a file so that they can be read when the uninstall starts.

Best regards,
Catalin

[sasha]

Thanks Catalin.

I understand that's the way the MSI works. But it does appear that the product being uninstalled has its command line created by the new version. The properties are provided on the command lie, it's just their values are empty.
Why provide the arguments and not their values? Maybe this is a question for Microsoft? But then who creates this command line? AI or MSI?

Executing op: CustomActionSchedule(Action=_F79B2DE2_FB27_43A1_83E5_D28BD8CCD97C,ActionType=3089 ....

Thanks.

[Catalin]

Hello Sasha,

Why provide the arguments and not their values? Maybe this is a question for Microsoft? But then who creates this command line? AI or MSI?

The MSI is created by Advanced Installer, but as you suspect, the command line is created by the Windows Installer.

The two actions that are used during an upgrade are: FindRelatedProducts and RemoveExistingProducts.

Both these actions are "standard" and proprietary to Windows Installer and therefore we do not have any "power" over it.

This is one of the big advantages MSI based packages offers as opposed to non-MSI packages.

Hope things are clearer now!

Best regards,
Catalin

[sasha]

Thanks, Catalin. Maybe you guys can file a bug report with MSFT?

[Catalin]

You are alwyas welcome, Sasha!

Maybe you guys can file a bug report with MSFT?

I'm afraid that even if we did that, nothing would change, as this technology has been the same since early 2000's and it is not regularly updated.

Best regards,
Catalin