cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
SMM-OSSI
Level 3

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:


  • Version 1.0.0.0
    Already installed in C:\Program Files (x86)\Company\Product

    Registry 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.1
    When 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\A

    HKLM\...\Product\Items\B

    HKLM\...\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\A

    HKLM\...\Product2\Items\B

    HKLM\...\Product2\Items\C




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
  • Labels (1)
    0 Kudos
    (4) Replies
    chad_petersen
    Level 9

    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
    0 Kudos
    chad_petersen
    Level 9

    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

    0 Kudos
    chad_petersen
    Level 9

    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
    0 Kudos
    chad_petersen
    Level 9

    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
    0 Kudos