This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Changing Product Name for Upgrade
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 06, 2017
10:40 AM
Changing Product Name for Upgrade
We are making a slight change to the name of our product, which means I need to modify the installer so that it installs to a new folder and the registry key name should also change. I have tried many things and I keep getting 1316 (Specified account exists) errors, old folders that aren't removed, two installations...you name it.
InstallShield 2015, BTW
Take the following scenario:
I need to create an upgrade so that when it does the upgrade, it changes the following:
One of the tricky things is that during the initial setup of 1.0.0.0, the user can select some items to install and those options are stored in the registry. When I run the upgrade, I don't want to rerun that prompt and instead simply upgrade any selections they made during the initial installation.
So let's say during the initial installation, they selected item A, B, C for installation, but not D, E, F. The registry would have:
During the upgrade, I don't want to prompt them again. I just want to upgrade A, B, and C as needed. So I can't just blow away the registry for this application. Instead, I want to rename it so that it looks like:
So I wondering which of the following options are best and how to do them:
[LIST=1]
Do a complete uninstall of 1.0.0.0 and then install 1.0.0.1. I tried creating a major upgrade and selecting the 'Completely uninstall old setup...' option, but this didn't seem to have any effect. This would be my preferred method, if I could figure out how to preserve the registry items selected from the initial installation.
Update 1.0.0.0 to 1.0.0.1 and, at the same time, rename the install directory and registry to the new paths. My fear of doing this is that there are probably a ton of references to these paths all over the system (under-the-hood stuff). This seems more like a hack, and not the proper way to do this. Not to mention, I have tried this and am not having any luck. 😮
I should also point out that the lead developer is really adamant about not changing the other parts of the version number. Unless I can demonstrate that that would be the only way to get this working, he won't budge.
Any help would be greatly appreciated.
Regards,
Scott
InstallShield 2015, BTW
Take the following scenario:
- Version 1.0.0.0Already installed in C:\Program Files (x86)\Company\ProductRegistry entries are created in HKLM\SOFTWARE\WOW6432Node\Company\Product
I need to create an upgrade so that when it does the upgrade, it changes the following:
- Version 1.0.0.1When upgrading, change the install directory to C:\Program Files (x86)\Company\Product2. The old directory should no longer exist on the system.Registry entries should be changed to HKLM\SOFTWARE\WOW6432Node\Company\Product2. Like the directory, the old registry key should no longer exist on the system.
One of the tricky things is that during the initial setup of 1.0.0.0, the user can select some items to install and those options are stored in the registry. When I run the upgrade, I don't want to rerun that prompt and instead simply upgrade any selections they made during the initial installation.
So let's say during the initial installation, they selected item A, B, C for installation, but not D, E, F. The registry would have:
- Version 1.0.0.0:HKLM\...\Product\Items\AHKLM\...\Product\Items\BHKLM\...\Product\Items\C
During the upgrade, I don't want to prompt them again. I just want to upgrade A, B, and C as needed. So I can't just blow away the registry for this application. Instead, I want to rename it so that it looks like:
- Version 1.0.0.1:HKLM\...\Product2\Items\AHKLM\...\Product2\Items\BHKLM\...\Product2\Items\C
So I wondering which of the following options are best and how to do them:
[LIST=1]
I should also point out that the lead developer is really adamant about not changing the other parts of the version number. Unless I can demonstrate that that would be the only way to get this working, he won't budge.
Any help would be greatly appreciated.
Regards,
Scott
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2017
12:42 PM
I believe we already discussed this before - see post #5 in this thread
https://community.flexerasoftware.com/showthread.php?222571-ProductCode-and-UpgradeCode-out-of-sync
However, even though MSI itself only recognizes the first 3 number segments for it's own upgrade purposes and you have to follow the rules that it enforces - this ONLY applies to the Product Version in the installer itself - it does NOT apply to all of the files that you might include in your installer for delivery onto the target system. Those can be completely different versions than the installer itself. Not sure if maybe that point was lost.
But, yes, what you describe is the way it works. MSI does not recognize any difference between two installers that only vary in the fourth segment of the Product Version. The fourth segment is the "Build" number and Microsoft decided a LONG time ago that one build should not be considered an upgrade to a prior build. Don't ask me "why", it's just the way it is.
Chad
https://community.flexerasoftware.com/showthread.php?222571-ProductCode-and-UpgradeCode-out-of-sync
However, even though MSI itself only recognizes the first 3 number segments for it's own upgrade purposes and you have to follow the rules that it enforces - this ONLY applies to the Product Version in the installer itself - it does NOT apply to all of the files that you might include in your installer for delivery onto the target system. Those can be completely different versions than the installer itself. Not sure if maybe that point was lost.
But, yes, what you describe is the way it works. MSI does not recognize any difference between two installers that only vary in the fourth segment of the Product Version. The fourth segment is the "Build" number and Microsoft decided a LONG time ago that one build should not be considered an upgrade to a prior build. Don't ask me "why", it's just the way it is.
Chad
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2017
12:45 PM
Here's the reference on Microsoft's web site - since you obviously are not trusting some information being given
https://msdn.microsoft.com/en-us/library/windows/desktop/aa369786(v=vs.85).aspx
Specifically the section in gray that says.
Note Windows Installer uses only the first three fields of the product version. See ProductVersion Property for descriptions of these fields. If you include a fourth field in your product version, the installer ignores the fourth field.
Good luck!
Chad
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2017
12:50 PM
Sorry, I used the term build for the number but some refer to that field as revision. Doesn't really matter what you call it, it is ignored for upgrades
major.minor[.build[.revision]]
or
major.minor[.maintenance[.build]]
Chad
major.minor[.build[.revision]]
or
major.minor[.maintenance[.build]]
Chad
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2017
12:57 PM
Oh, and you could read the registry keys and store their settings in various PROPERTIES and then use that information as you write back out to your new location.
I use a similar approach with a 64-bit overlay installer - it reads all of the registry keys set by the 32-bit installer and then writes those same values to the 64-bit section of the registry, which the 32-bit installer doesn't have access to.
Works slick.
Chad
I use a similar approach with a 64-bit overlay installer - it reads all of the registry keys set by the 32-bit installer and then writes those same values to the 64-bit section of the registry, which the 32-bit installer doesn't have access to.
Works slick.
Chad
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)