ITNinja

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?

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.

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?

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.

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

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?

PJ

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.