5 replies to this topic

[longmian]

Hi, there,

I came across a question that I could not seem to get a definitive answer for. Hope one of you can shed a light on it.

I was trying to retrieve an MSI property of a product in a script. The MSIGetProductInfoProperty() call always returns blank on "INSTALLPROPERTY_INSTALLDATE" (it is supposed to return a date string).

My question is: how does MSI tell if a product is installed or not?

Some document suggests that it check ProductCode, UpgradeCode and ProductVersion. So, it searches the registry, local drive, or both? What is the sequence of events performed by MSI in determining the existence of a product?

Thanks you all in advance!

Longmian

[Stefan Krueger]

I believe it basically looks for the ProductCode, which is stored somewhere in registry for all installed products. However the GUID is not stored plain but "Compressed".

[longmian]

Thanks, Stefan.

You are right on point, I think. This is something I suspected too. Could the information in here:

HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\SID\Products\SomeID*\Features

Note that "SomeID" (with an *) is not the ProductCode - it seems to come from nowhere and varies from installation to installation. Anyway, I was able to track it down since it associates with my product. As a matter of fact, I only only find the ProductCode (the plain GUID) in places like "UninstallString" value, but never as a key.

Back to your obversation. If the ProductCode is compressed, is the compression documented? Or how to decompressed it?

Just a little background about what I wanted to do. I need to do an update on a product which has a different ProductCode than my update and Maor update is not the solution (the marketing does not like the idea of Uninstall/install of major upgrade). So, I may have to tweak the registry before hand so that my upgrade installer thinks I am actually doing a minor upgrade - basically, to modify the registry to trick MSI.

Thank you!

[antyagi]

Quite simple, the so said compression is actually a manipulation of ProductCode.

If ProductCode is:
"{abcdefgh-ijkl-mnop-qrst-uvwxyz123456}"
The manipulated ProductCode (compression) will always be:
"hgfedcbalkjiponmrqtsvuxwzy214365".

First three parts are inverted and concatenated.
For last two parts the inversion is done in sets of 2 digits, and then concatenated.

I don't know if i am 100% right; but this is what i have observed with a lot of products.

ankur

[longmian]

That helps a lot for me to understand the PrpductCode, Ankur.

However, after changing the ProductCode, the UpgradeCode to match the ones that are in my "Upgrade" table, my upgrade installer simply displays a "Removing" message and disappears immediately. I even could not get the debugger to stop anywahere in my InstallScript.

Could anyone explain how the upgrade installer works?

Thanks!

[longmian]

The more I dig into this, the more interesting it is getting...

By changing the registry items (ProductCode, UpgradeCode...) to match the ones that are defined in my previous installtion on the target machine, the upgrade installer now is able to recognize the product as somehow "installed". However, when query the "Installed" property of the installed product, I still got nothing (means Not Installed). A subsequent query to the "ProductState" property returns "2" - means it is installed for a different user! I knew my product was installed for "All users" by an administrator! So, why the hack MSI thinks it is installed for someone else? A registry or somewhere is secretly checked by MSI - I guess - which I did not change.

The question now becomes: What MSI will check before it sets the "Installed" property?

Any idea?

Thanks a lot.

Edited by longmian, 09 February 2006 - 03:41.