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 to solve Component ID mismatch issue during upgrade.


10 replies to this topic

ashik

ashik
  • Full Members
  • 3 posts

Posted 12 March 2014 - 06:21

I have a setup which has certain component IDs.
But some of these Component IDs do not match the IDs of the Setup with which I have to upgrade the previous setup.

Say, for the same component abcd.exe, both setups have different component IDs.
Setup 1 had Component ID : {9E5018E0-5707-4B03-A937-B4DA13BA7E1B}
Setup 2 has Component ID : {21741DCA-DDEC-48AC-9CBC-EE458DC0E063}
Due to this, when upgrade is performed by Setup2 over setup1, it fails.

Other than major upgrade option, do I have any other option so that upgrade works successfully.
I have tried to update the component table using MSIDatabase functions, but the msi database gets corrupted.
Please do let me know how to solve this issue.

 

Note: The component IDs were not changed purposefully.
Some deletions took place due to which the component ID got changed.


Edited by ashik, 12 March 2014 - 06:46.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 12 March 2014 - 14:42

Can you adjust the new setup to make it use the same IDs that were used in the old version?

Otherwise, I'd recommend a Major Upgrade.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 12 March 2014 - 16:15

I don't have Installshield installed at this point, but there is an option to synchronize guids for dynamic components (the components that include files automatically at build time - if that is what you have used), I think this is called Patch optimization or something like that - it is in the release view as far as I recall and involves pointing the new MSI to the path of the old MSI so that the guids can be syncronized. I doubt, however, that this is enough in this case since you may have hard coded these guids using regular components

 

There are two options that I can see: 

 

1: Major upgrade that uninstalls the existing product before reinstalling the new one. You must move RemoveExistingProducts before InstallInitialize in the InstallExecuteSequence to achieve this. You can not deliver a patch using this approach (neither major or minor upgrade patch will work).

 

2: You manually go through your setup and sync each component guid in the new setup with those of the older version. Not impossible to do, but a lot of tedious work. If you do this you should be able to deliver a minor upgrade patch. This, however, is a whole other story and is quite complicated to begin with - your setup may have other constructs that would prevent it.

 

All in all, I would chose option 1 and from now on make sure to not change the component GUIDs.


Edited by Glytzhkof, 12 March 2014 - 16:16.

Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 12 March 2014 - 16:37

You mentioned you removed components - that's another thing which would break minor updates.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 12 March 2014 - 18:06

Yes, sorry missed that. Thanks Stefan. One more thing: a major upgrade patch is possible if you clean up the component GUIDs and move RemoveExistingProducts late in the InstallExecuteSequence, but the value of such a patch is limited if the application isn't extremely large. It is complex to make and test. It is not recommended to go down that path.


Edited by Glytzhkof, 12 March 2014 - 18:08.

Regards
-Stein Åsmul

ashik

ashik
  • Full Members
  • 3 posts

Posted 13 March 2014 - 05:04

Other than major upgrade and adjuesting the component IDs manually, Is there any other option?

The reason is that I have other setups too for which upgrade should be successfull.

 

Consider the below case,

I have SetUp1 and SetUp2 as specified above .

Also there is another setup, SetUp3 which has the same component ID as in SetUp2.

So When upgrade is performed, SetUp2 over setup3 it is successfull.

But when upgrade is performed, SetUp2 over setup1 it fails.

 

I need a solution so that both upgrades, setup2->setup3 and setup2->setup1 are successfull.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 13 March 2014 - 15:21

1: Major upgrade that uninstalls the existing product before reinstalling the new one. You must move RemoveExistingProducts before InstallInitialize in the InstallExecuteSequence to achieve this. You can not deliver a patch using this approach (neither major or minor upgrade patch will work).

 

This option will solve your upgrade problems, but patching will not be possible. Patching is merely a different delivery mechanism for an update, and is possible to do without.


Regards
-Stein Åsmul

overlord

overlord
  • Full Members
  • 38 posts

Posted 19 March 2014 - 14:11

As another option you can zero out the install condition on the components you want to remove and set the flag to re-evaluate install conditions. This will allow you to perform a minor upgrade and still remove components from the installed system. The installer will still have them but will remove them from the system if it detects them. If installer size is a big concern you can add dummy place holder files that are empty and have the correct names. The GUIDs will HAVE to match though in order to pull this off. 

 

So if you needed to keep the new guids you could add a second component with the old guid and then follow the steps i mentioned above to remove it and use only the new one going forward. This is likely your only other viable option if you have already released a version with conflicting guids and want to be able to upgrade and support both from a new installer. 

 

so using your example:

 

Setup 1 had Component ID : {9E5018E0-5707-4B03-A937-B4DA13BA7E1B} is lets say version 1.0
Setup 2 has Component ID : {21741DCA-DDEC-48AC-9CBC-EE458DC0E063} and this is version 1.1

 

 

you are creating setup 3 that is version 1.2 and you want to be able to install over both setup 1 and 2.

As such you will need a component with the same files for each GUID.

 

setup1's guid will be your dummy guid. set the install condition to 0 and flip the re-evaluate condition to 'yes' and add all the files that were in the component in setup 1 (version 1.0)

Setup 2's guid will be your component going forward. so add another component with this guid to setup3 with all the files that are in setup 2 (version 1.1)

 

 

this should allow setup 3 to properly perform a minor upgrade over setup1 (assuming you didnt violate any other upgrade rules). by removing the old component and dropping the new one in its place.

this should also allow a minor upgrade over setup2 as the component id should be the same. One of the posts on my old account has some really helpful information from Stefan about this. Ill see if I can dig it up.

 

edited for clarity


Edited by overlord, 19 March 2014 - 14:43.


ashik

ashik
  • Full Members
  • 3 posts

Posted 21 March 2014 - 05:09

Can anything be done using the function FeatureRemoveAllInLogOnly().

The document this uninstalls the features previously installled package and not present in the current package.



overlord

overlord
  • Full Members
  • 38 posts

Posted 21 March 2014 - 14:39

To my understanding not if you want to perform a minor upgrade or Patch. If you remove a component you are violating the conditions needed for that upgrade. If you attempt to run a minor upgrade when you violate these rules you get wildly unpredictable behavior. 0'ing out the condition on a component is a work around for removing a component. If you don't care about the minor upgrade rules and or that mechanism for replacing files then as previously stated by other posters a major upgrade is your best bet.

 

 

EDIT -  I couldnt find the post but I am 90% sure Stefan and possibly TacoBell helped me with this situation previously.


Edited by overlord, 21 March 2014 - 17:31.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 24 March 2014 - 16:47

Agree with overlord: you can set the component condition to 0 (which means "false") and re-evaluate to yes.

FeatureRemoveAllInLogOnly only applies to pure InstallScript projects, not MSI.