Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

How a major upgrade removes the old version


7 replies to this topic

Irina

Irina
  • Members
  • 227 posts

Posted 21 August 2002 - 19:14

Hi all,
A system have had installed a version 1.0 of the product. A user have modified some installed files and created several new files and folders. The major upgrade from 1.0 to 2.0 is applied. This upgrade executes the RemoveExistingProducts action to remove the old (1.0) version. What's happend with these user files and folder? Will they be deleted or still presented?

Thanks for any answers,
Irina Shirinsky
Software Engineer, Heroix Corporation
http://www.heroix.com

Irina

Irina
  • Members
  • 227 posts

Posted 22 August 2002 - 17:27

Hi,
I have found the answer. Maybe it will be helpfull for somebody. The RemoveExistingProduct executes an uninstallarion of the detected product. So the behavior is the same as during the uninstallation of the product.
Thanks
Irina Shirinsky
Software Engineer, Heroix Corporation
http://www.heroix.com

Ian Blake

Ian Blake
  • Members
  • 483 posts

Posted 23 August 2002 - 16:43

To clarify a little further.  It uses the old msi to uninstall not the new database.  This means if you have done something unwise in the old database you may not be able to upgrade in the ideal fashion.

The RemoveExistingProducts action can be placed in different locations.   If it is placed early in the execute sequence the old product is completely removed.  Then all the files of the new product are installed.  If it is placed at the end only new and upgraded files will be installed which is usually a better option.

If you execute custom actions for uninstall then you need to ensure they are properly conditioned.  REMOVE="ALL" is not very useful here.
Ian Blake
(Currently Unemployed)

Irina

Irina
  • Members
  • 227 posts

Posted 23 August 2002 - 17:02

Hi Ian,
Thanks for this clarification. I have tried different way to use the RemoveExistingProduct action. I put it after InstallFinalize which is better. You are right when I left a Remove field empty in the Upgrade table (it means REMOVE=ALL") then my old version of the product was completelly removed. My unistallation deletes leftover registry keys and user files, so I have lost a significant part of my product after this action. I have put to the Remove field an empty string (like empty property). In this case no files have been removed. All were updated, registry keys were updated also.

BUT I have had two entries in the Add/Remove Program panel for old and for new versions. Could you please tell me how I can avoid this?
As far as I understand if I put in the Remove field a features list I will still have two entries in the Add/Remove Program.

Another one problem is a significant amount of time which this upgrading will take.

I would be greatle appreciated for any help.

Thanks a lot,
Irina Shirinsky
Software Engineer, Heroix Corporation
http://www.heroix.com

Ian Blake

Ian Blake
  • Members
  • 483 posts

Posted 23 August 2002 - 21:53

I tie my custom actions to components.  By using conditions checking the install and action state of a component it is possible to determine if it is necessary to run a custom action or not.

In the install phase of a product is executed the installer adds instances of the new product guid to the registry msi database under each component key.  In an install remove phase if the installer deletes the product guid.  If there is another guid there it does not remove the component and the action state is set accordingly.  If this is the only guid the component is marked for removal.


Upgrade Product 1 to Product 2

Add new Component A
Overwrite Component B with new version
User deslected Component C is removed
Publish components
registry
 Component A - Guid 2
 Component B - Guid 1 & 2
 Component C - absent
 Component D - Guid 1 (not in product 2)
RemoveExistingProducts
 Component A - GUID 1 not present no action
 Component B - remove Guid 1 but not component
 Component C - absent
 Component D - only GUID 1 present remove component
Publish components
registry
 Component A - Guid 2
 Component B - Guid 2
 Component C - absent
 Component D - absent


This is a simplification but it broadly explains what I think goes on.
Ian Blake
(Currently Unemployed)

Irina

Irina
  • Members
  • 227 posts

Posted 23 August 2002 - 22:20

Hi Ian,
1. If I will change GUID for all my components in the product for the new version 2.0 and then apply a major upgrade, then files will not to be removed, will be only remove GUID references in the registry on the old version. Is it correct?

2. About condition for the custom action. I have used a condition "REMOVE=ALL" in my old version 1.x to remove leftover files and registry key. I can not change these conditions now because they already exist in the msi package which is installed on computers. So if I will execute RemoveExistingProduct action all files from the user profiles folder will be removed and then folder itself will be removed also. It seems to me I can not do anything to prevent this.
Could you please let me know if you have any ideas.

Thanks a lot,
Irina Shirinsky
Software Engineer, Heroix Corporation
http://www.heroix.com

Ian Blake

Ian Blake
  • Members
  • 483 posts

Posted 26 August 2002 - 19:16

1.  The files will defintely be removed if you change the component guid. You almost certainly do not want to do this.

2.   It is easy to make mistakes in an older install before you get a good appreciation of msi.  When I did this on my first installs all I could do was to detect the earlier installs and refuse to upgrade without the old version being uninstalled first.  I am now consider upgrade implications from the initial design of an install. (Not that I do installtion anymore).

I have never tried this you might be able to modify the cached install if the file is not locked. It probably will not be before FindRelatedProducts.  Delete the offending line from the old cached msi database.  Tricky but educational.
Ian Blake
(Currently Unemployed)

Irina

Irina
  • Members
  • 227 posts

Posted 27 August 2002 - 13:42

Hi Ian,
Thanks for you reply. As far as I understand there is only one way for me now to do an upgrade. This is a modifying a cached install package. I will be probably trying to do that.
BUT my upgrading takes a significant time against the clean install (like 25 minutes against 5 minutes), The problem is I don't see a mouse pointer in a dialog immediatelly. It looks like the installation hang, it comes back, but a customer may decide the installation doesn't work properly. Do you know what may cause this and could I do anything with this?

Thanks a lot,
Irina Shirinsky
Software Engineer, Heroix Corporation
http://www.heroix.com