4 replies to this topic

[GalwayDude]

Hi Guys, need help on this one! Our product currently installs into C:\Program Files\Prod1. We have since rebranded the product and the customer now wants it in C:\Program Files\Prod2. So far, so good.

My problem : If i try to upgrade, its gets installed into the Prod1 folder. If I change the product code and treat it as a Major Upgrade, it installs into Prod2 folder but leaves Prod1 where it is. Our customer is not happy that there are now two entries for this Product in Add/Remove programs, two folders in Program files etc.

Any ideas on how to handle this? Ive tried including a small .Exe or .Bat file with my MSI to call Msiexec and use a command line uninstall, but the msiexec command is not being called! Its as if it wont fire while the install of the other project is underway. (it has no problem working on its own) Im afraid this really has to be done in the one MSI as the customer does not want two or more setup steps to have to follow.

Any thoughts on this appreciated. Thanks for reading!

[mpento]

The fact that you have 2 entries in your Add/Remove Programs list for your product indicates that you upgrade is not authored correctly.

Generally speaking, you need to change the ProductCode GUID (NOT the UpgradeCode!), bump the version of the install and author a major upgrade item which will completely remove the existing install and install your new version in the correct location.

Hope this helps,
Mike

[Zweitze]

Go for the major upgrade solution and ensure that the RemoveExistingProducts action is scheduled before InstallInitialize.

[GalwayDude]

Thanks for the replies guys. I had already tried what ye suggested to no avail. As a work around, I just created a VB .Exe to handle the uninstall and new install sequentially. I dressed it up to make it look like an IS dialog so the user wouldnt complain.

Not a perfect solution but time was against me! Thanks again.

[Glytzhkof]

When moving a product to a new folder there is one added complexity: the component GUIDs and how this affects component reference counting.

The overall idea of MSI is that there is to be a one-to-one mapping between a component GUID and an absolute path. So the rule of thumb is: if you change the component GUID, you need to change the absolute path and the other way around, if you change the absolute path, you should change the component GUID:

Component GUID <-> C:\Program Files\Test.exe (absolute path / key path).

What you are doing when changing the installation folder AFTER a product has been installed is to confuse this reference counting. Ideally I believe the following should be done:

* Change product code & package code
* Bumb version number
* Change ALL component GUIDs for moved files
* Ensure that all component key paths point to new absolute paths