Printable View
We have a 32 bit app and installation that we have rolled out to clients. We're now working on the next version, but seeing that the Get Related Product call (which we pass the Upgrade Code GUID) doesn't find the previous version on 64 bit machines. I set the "Package Type" to x86 for the Get Related Product call because we have a 32 bit app. Is that not correct? How can I get this function to work correctly for 64 bit?
Mark,
Would you like to detect a previously installed version? You can use "Detect Previous Version..." to handle this.
Friedrich
We could use that, but does that detect a product based on the Upgrade GUID or the strictly the product GUID (of its individual version).Quote:
Originally Posted by linder
We often have clients that have not installed the most recent version, so may be one or two "steps" behind. All previous version use the same Upgrade GUID, so that's why I wanted to use that.
Mark,
See attached screenshots. The setup installed an initial 1.00.1234 test version (32-bit). The "Get Related Products..." script function detected this version without any problem on Windows 7 Ultimate Edition x64.
BTW, I noticed that for unkown reasons, the documentation for this function is "incomplete" (seems to be caused by a copy and paste error). We'll fix this in the next documentation update.
Does this help?
Friedrich
Yes, with one exception: what impact does the "package type" selection have?
Mark,
We introduced the "Get Related Product..." function some years ago for internal use to handle Microsoft redistributable runtime detection. Three years ago we opened this function for public use and beginning with V7.5, the SB installer created the Upgrade GUIDs by default. Microsoft's Upgrade GUIDs are always stored in the 64-bit registry branch on x64 Windows (even if the installed package is 32-bit). The "x86" and "x64" Package Type options instruct the installer to access this location.
If you are using "Get Related Product..." to detect a 32-bit mode SetupBuilder generated Upgrade GUID, please select the "None" Package Type.
Friedrich
Ok, I had set it to x86 since we have a 32 bit app - we'll retest with the call set to "None."
Sorry for the inconvenience caused by the documentation issue. We'll fix it in the next documentation update.
Friedrich
We've confirmed setting the function to the "None" type works correctly on all platforms. Thanks for your help!
Thank you for the update, Mark.
Friedrich