Problem with Major Upgrade in InstallShield 2015 (And Registry Editing)

[Nerevarine]

Hi,
Im new to InstallShield 2015, Im interested in using the major upgrade feature of installshield.

So far Ive done :
1) Create a new Upgrade Item in Upgrades tab.
2) Change Product Version, Code and Package Code.
3) Reinstalling it using the newly built msi.

My problem is, upon running the newly built MSI, it is not uninstalling the previous version. It doesnt detect the previous instalation at all.
Id like a fix for this problem, Ive browsed the forums for this problem and Ive noticed this is a very common problem.

Thanks in advance

[Lurban]

Here is what Microsoft says about it's placement:

<>

RemoveExistingProducts Action

The RemoveExistingProducts action goes through the product codes listed in the ActionProperty column of the Upgrade table and removes the products in sequence by invoking concurrent installations. For each concurrent installation the installer sets the ProductCode property to the product code and sets the REMOVE property to the value in the Remove field of the Upgrade table. If the Remove field is blank, its value defaults to ALL and the installer removes the entire product.
The installer only runs the RemoveExistingProducts action the first time it installs a product. It does not run the action during a maintenance installation or uninstallation.
Sequence Restrictions
The RemoveExistingProducts action must be scheduled in the action sequence in one of the following locations.
Between the InstallValidate action and the InstallInitialize action. In this case, the installer removes the old applications entirely before installing the new applications. This is an inefficient placement for the action because all reused files have to be recopied.
After the InstallInitialize action and before any actions that generate execution script.
Between the InstallExecute action, or the InstallExecuteAgain action, and the InstallFinalize action. Generally the last three actions are scheduled right after one another: InstallExecute, RemoveExistingProducts, and InstallFinalize. In this case the updated files are installed first and then the old files are removed. However, if the removal of the old application fails, then the installer rolls back both the removal of the old application and the install of the new application.
After the InstallFinalize action. This is the most efficient placement for the action. In this case, the installer updates files before removing the old applications. Only the files being updated get installed during the installation. If the removal of the old application fails, then the installer only rolls back the uninstallation of the old application.

[chad_petersen]

There are a handful of reasons it can fail to find an existing product. Here are two of the most common given the other things you mentioned sound correct.

Version number - only changing the fourth tuple. MSI ignores the fourth tuple for upgrades. All version number changes must occur in the first 3 tuples. A 4 tuple version number IS valid, MSI just ignores the fourth one for upgrades. So 17.1.1.0 looks exactly like 17.1.1.1 to MSI. Could this be the case?

http://www.installationdeveloper.com/979/a-close-look-at-version-numbers-in-the-windows-installer-2/

Per User versus Per Machine installs - if a change is made from being a Per User install to a Per Machine install, or vice versa, then it won't upgrade. You'd be surprised how common this is.

https://www.indigorose.com/webhelp/msifact/Concepts/Per-Machine_vs._Per-User_Installations.htm

See if either of those are the case and let us know what you find.

Hope that helps some.

Chad

[Nerevarine]

Thank you, managed to fix the problem after following your suggestion.
It seems, I needed to update the Upgrade Table manually.
The upgrade code was {00000000000000000000} initially