cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kenzo22
Level 6

Upgrade code in registry

Hello all, I assume upgrade code will be writen into the registry when a msi package is installed. But today when I check the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes, I can't find the corresponding upgrade code of an installed msi package, so what could be the reason?
Labels (1)
0 Kudos
(13) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Microsoft doesn't support manually probing registry keys like this. If you want to check for an installed product, you should use a Major Upgrade item (which creates an entry in the Upgrade table), or a call to FindRelatedProducts (or equivalent) in a custom action.
0 Kudos
kenzo22
Level 6

Hello Michael, actually our installer wants to configure a system search to check whether another product have been installed, but there are several versions of that product with different product code, so I am not sure what registry should I check, I know the update code will never change for a product series, but as you say, upgrade code will not be written into registry unless that product launches a major upgrade, so can you provide some suggestions about the system search, thanks 🙂
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Again, you should use a Major Upgrade item or a call to the FindRelatedProducts API (or equivalent). Both of these search by UpgradeCode.
0 Kudos
kenzo22
Level 6

Sorry, I am not quite understand. I am a newbie to InstallShield, so please correct me if I am wrong. I think major upgrade item is used to remove the old version product and install the new version one and both the old and new ones are the same series of pruducts. However, in my case, A and B are not the same series of products, I just want to notify users to uninstall A before installing B. As I said before, there are many versions of A installed on users' computer, so it's not possible to search their product code in the registry(obviously they have different product codes) to prove A's existense, although all versions of A share the same upgrade code, but I can't find the upgrade code in registry, so I am confused how to configure the system search to prove A's existence on the target system.
0 Kudos
RobertDickau
Flexera Alumni

Actually, there's a "detect only" kind of major upgrade item, where Windows Installer looks for products with a given upgrade code and populates an MSI property with the product codes of the result, but never removes the product.

If you look in a new InstallShield project, you'll see a major upgrade item that detects newer versions of the product, which does the same thing; you can create a similar item that looks for older versions.

This old newsletter tip talks about the general idea, but without the "detect" part (PDF): http://www.flexerasoftware.com/webdocuments/PDF/nl_article_DEV_MajorUpgradeUI.pdf.
0 Kudos
kenzo22
Level 6

Hello Robert, thanks for your response. Following you suggestion, I have configured a major upgrade item and filled in the upgrade code of the product I want the installer to check, and also set detect only to "yes", see attached images. But how can I use the check result to notify users to uninstall this product before installing our product, I configured an install condition "Not ISACTIONPROP2" but it seems doesn't work.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I believe Install Conditions are evaluated before Major Upgrade items are processed. Because of this, you will have to use a custom action to exit the installer. The process to follow for this is very similar to that for preventing downgrades; only the message and the search parameters on the major upgrade item will differ. http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/PreventingDowngrades.htm
0 Kudos
kenzo22
Level 6

Michael, I followed your suggestion to create the custom action, but I still ecounter some problem. Something in the log: "FindRelatedProducts: current install is per-user. Related install for product '{1CD2CB71-4075-4B7B-BAC5-DDA3AFE77A72}' is per-machine. Skipping...", I think in this situation the "detect property" I defined will not save the "product code", and this makes the condition for my custom action to "false". I read from another thread saying "detection works only for packages which have the same installation type, you cannot use it to detect an older version with a different install type." you can check the whole thread http://www.advancedinstaller.com/forums/viewtopic.php?f=2&t=7907 , It would be so much easier if the "Detect only" option for upgrades actually saved that Product Code, regardless of the installation type.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Sounds like you might need to write some code, as the built in data-driven patterns don't satisfy your needs. The FindRelatedProducts API I referenced above is either (C++) MsiEnumRelatedProducts or possibly (VBS) the Installer.RelatedProducts Property. If you write it in C++, you can then use MsiProcessMessage to inform the user and then return ERROR_INSTALL_FAILURE to abort the install, or you can set a property with MsiSetProperty much like the FindRelatedProducts action does and abort with a type 19 custom action. You can probably do similarly in VBS, but I'm much less familiar with that approach.
0 Kudos
kenzo22
Level 6

Actually I should set "ALLUSERS" property to "1" to ensure a per machine install, this setting will make the problem "FindRelatedProducts: current install is per-user. Related install for product '{1CD2CB71-4075-4B7B-BAC5-DDA3AFE77A72}' is per-machine. Skipping..." disappear, however, the custom action still doesn't execute(condition is "false" in log), I followed the instruction here http://kb.flexerasoftware.com/doc/Helpnet/installshield14helplib/PreventingDowngrades.htm 1.set detect only to "yes" 2. use the detect property "ISACTIONPROP2" as condition of the custom action, please see attached images.
0 Kudos
dearsuresh
Level 3

Dear Friends

I need some urgent help from you guys...

advance thanks to u..

I am new to installershiled...my problem is i created new installer with my install shiled 12..

after i added all my dlls and all...and i did "batch build" to create new installer file..everything going good..but new installer is coming with "Programfiles folder".in that programfiles folder have all dlls which i include in code,,,now i copied my generated installer file and try to install,,its saying some dll is missing,,

but i copied whole new release folder and try to install,,its installing,,becoz in that folder all dlls is there in program folder,,,now my questions is why new program file is creating with all dlls...i want to use one .msi file to test other system,,its not good to give whole folder to client....pls give me idea why its creating new program files folder will all dlls

thanks in advance

regards
edara
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

@kenzo22 - my mistake; I misread and thought the previous package was per-user and you were moving to per-machine. In that case, the question is what happens to ISACTIONPROP2 around FindRelatedProducts. If it's still not finding anything, does the existing install fall outside the version bounds on your Detect-only item? Currently you are limiting the found versions to those less than the version of the product you deploy. If this represents a new version scheme as well, perhaps try a hardcoded Max Version of 99.99.9999 or so (or something more specific to what you want to remove)?
0 Kudos
kenzo22
Level 6

Great, Michael, after I change the setting "Any earlier version" to a hardcoded Max Version of 99.99.9999, everything works fine. Thanks very much for your great help 🙂
0 Kudos