Home/ Questions/Q 3692474
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T04:16:00+00:00

(EDIT: Question changed.) I have a product with an installer which was built by

  • 0

(EDIT: Question changed.)

I have a product with an installer which was built by InstallShield 2010, and appears by all accounts to be installing just fine as a “new” install.

Periodically, I make changes to the contents of the installation, as I update this or that component with bug fixes and so forth. At those times I try to change the version numbers in the metadata of the files that got updated, but there are components for which that isn’t possible. Of course they always end up with more recent modify dates. I change the version number for the product in the MSI data as well. However, I have not been changing the Package Code each time.

When some users run the installer on a system where my product is already present, they’re prompted with update mode UI (“would you like to update?” etc.) and the installer appears to complete. However, the updated files don’t always overwrite the older files until a “repair” installation is run afterwards, especially if the version number didn’t change, and there is evidence now that flagging the component’s contents with a “force overwrite” doesn’t change this behavior.

What’s going on here? Is there any way I can get a better result? Does the Package Code need to change whenever I rev the product or update a component? (Edit: The Package Code is changing each time I build the release, so this is not the cause of the problem.)

Edit: It’s an update UI, but maintenance after update is what actually completes the desired installation.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You should certainly be changing the PackageCode every single build. In fact, by default, InstallShield has a build setting that does just this.

    In fact, the MSDN help topic Package Codes says:

    Nonidentical .msi files should not have the same package code. It is important to change the package code because it is the primary identifier used by the installer to search for and validate the correct package for a given installation. If a package is changed without changing the package code, the installer may not use the newer package if both are still accessible to the installer.

    This is why you are getting a Maintenance UI experience instead of an Upgrade experience.

    Now once you start doing this you are going to have to next consider do you want to support Minor Upgrades, Major Upgrades or Patches to service your application. It’s very important that you understand this and test your strategy before putting your installer into production.

    • 0