ITNinja Question

Major Upgrade Not Working...

04/20/2012 4747 views

Hi all,

I'm working on our new product install which will the version 10.0 family. We are coming from 8.6 and earlier. When I run the upgrade from 8.6.x to 10.0.1 all works as planned. Old version detected and removed and the latest is put in place.

I thought I would look ahead and ensure a Major Upgrade in our new version family worked as expected. When I try moving from 10.0.1 to 10.0.257, the old is not removed and I see two instances in Add Remove Programs.

I can't for the life of me figure out what is wrong. I bumped the ProductVersion, obviously. Changed the ProductCode and PackageCode and changed the MaxVersion field value in the Upgrade Table.

All I see in the Log is Not Related and I don't see the ISFOUNDCURRENT property set in the second log. Here are images of the Upgrade settings in InstallShield...

You can download and see the install logs here... http://community.flexerasoftware.com/showthread.php?p=477700#post477700

I even tried changing the Upgrade Code and creating a separate Upgrade table entry for the v10 family, but that didn't work either. On this new entry I tried including the MinVer, but to no avail.

I just can figure this out. It almost seems there is a problem using 10 versions at this point, but that's absurd.

Any help in this would be greatly appreciated!

Thanks MUCH in advance!!

0 Comments   [ + ] Show comments


Community Chosen Answer


First Question - Is Upgrade code the same for these applications as you have mentioned above..

If no - Put the right one there/

If Upgrade code is same, why not use just the same table as above and change the max version. Why to create 2 entries?

Answered 04/22/2012 by: piyushnasa
Red Belt

All Answers


I think you need to set the "Include Maximum Version" field to Yes, and like pyush said, stick to one line in the Upgrade table.

Answered 04/24/2012 by: pjgeutjens
Red Belt


I had a look in your logs and analysing the following lines:

InstallShield 9:48:56: UpgradeCode: {5FE03C0D-59DB-4A48-BF15-9DE0DE72DCFD}    MinVersion: 8.3.0    MaxVersion: 10.0.257    Language: 1033    Attributes: 0
InstallShield 9:48:56:     MyCompany OurProduct 2011 Server    {85E692A4-1689-4946-9D85-3DCC4122C8E4}    0    10.0.1     ***Not Related***


I get the impression it's somthing to do with the language setting that's causing the mismatch. Did you try with leaving this field set to <null> in the upgrade table?

Just as a test, what happens if you were to increase the version of the new package to say 10.1.0, does the upgrade still not work?

Answered 04/25/2012 by: pjgeutjens
Red Belt


The max version field does not need to be set to Yes as each upgrade will target earlier versions.

To answer some other questions.  Upgrade Code is consistent and there is only one upgrade entry in the table for all of these scenarios.  The images above were only included to show the changes made between the initial v10 and its upgrade.

If I leave the setting null, then the update does work.  I'm just curious why one would have to do that.  It would seem then, at least built through install shield, that particular languages could not be targeted.

I did notice that with the initial install of 10.0.1, choosing english, that the .mst that is extracted from Setup.exe contains or sets a template summary property of x64;0,1033,1036.  I wonder where the 0 is coming from or what that designates.

It definitely has to do with the language and I think some InstallShield process is mucking something up.

If I remove the second language offering from the v10 family, v10.0.1 to .257 Major Upgrade completes as expected.

I've even tried setting <architecture>;1033,1036 on the General Template Summary property and in the x64 bit release configuration as well as the Language field in the Upgrade Table, but that still didn't work.

I'm going to double check everything with our 32 bit version just to rull out anything fishy there.

Answered 04/27/2012 by: Superfreak3
2nd Degree Black Belt

  • Nope, not a 32/64 bit thing as the same unsuccessful Major Upgrade happens in the x86 world.

Nope - same things occur in the x86 world so Architecture differences is ruled out.

Answered 04/27/2012 by: Superfreak3
2nd Degree Black Belt


Answering some of your open questions:

the 0 in the Template Summary means 'language neutral'

the actual property that determines the language of an installation is ProductLanguage. this one should be set to one of the values that are listed in the template summary. So either 0, 1033 or 1036 in this case. I'm pretty sure this is also what then gets checked by FindRelatedProducts

Couild you check your 10.0.1 installation to see what value (if any) you set for that installer?


Answered 04/30/2012 by: pjgeutjens
Red Belt

  • When I open the .msi that was extracted from Setup.exe, the Product Language is 1033, however in some of the logs, it looks like when I upgrade to 10.0.257, the producted is detected as 0 then marked as not related. I think that 0 may be the cause of the problem. I just wonder how it is getting there (InstallShield build process) and why it is being placed there? What if I don't want this to be a language neutral package and I would like to target certain languages? Would that still be accomplished throught the Upgrade tables Language field entry?

What I've done to this point is to modify the Template Summary Property in the extracted .msi and the .mst to remove the 0 for both 10.0.1 and .257. I then install .1 from the Command Line applying the Transform. The same was then done for .257 and the Major Upgrade WORKED!!!.

Now, my question is, why is the 0 being put in the Template Summary Property at build time? If this is to designate language neutrality, what if I don't want my installer to be language neutral and I want to target specific languages? Is this still done through the Upgrade Table's Language field. I guess in this instance, this field should be populated with nothing or 0,1033,1036.

Answered 05/01/2012 by: Superfreak3
2nd Degree Black Belt

  • Adding 0 to the Language field in the Upgrade Table does allow the Major Upgrade to function as intended. Not sure if this is the best workaround. This has been escalated at InstallShield Support.
  • InstallShield now sees this as a but that limits the ability to target specific languages for upgrade. Placing a 0 in the language field of the update record or blanking that field is the workaround.
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ