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
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
How MSI tell whether a product installed or not
Started by
longmian
, Feb 06 2006 16:13
5 replies to this topic
Posted 06 February 2006 - 18:36
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".
Stefan Krüger
InstallSite.org twitter facebook
Posted 06 February 2006 - 20:55
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!
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!
Posted 07 February 2006 - 06:05
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
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
ankur tyagi
Posted 08 February 2006 - 21:08
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!
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!
Posted 09 February 2006 - 02:56
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.
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.