Major Upgrade Not Working...

[Superfreak3]

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. I've attached the 8x to 10 log and log from the 10.0.257 upgrade. I've also attached images of the Upgrade table settings.

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!!

[Superfreak3]

If you look at the logs, it appears that there is a problem with the language selection or that field in the Upgrade table.

It's pulled from the Upgrade showing 1033, but is being evaluated as related to the upgrade as 0. ?? Anyway, I read that if there are no language restrictions, leave that field in the table blank, which does appear to work. After removing that attribute or blanking that field value in the .msi, the Major upgrade proceeded as expected.

The only problem is that it does not appear that this can be blanked in the Upgrades view. If I blank that field in the IDE and switch views, when I return, the default English value, 1033, appears.

I guess I'll try populating that entry with our two supported language values to see what happens. I'm currently only testing English so I would have guessed it should have worked as is.

[Superfreak3]

Tried populating the Language with 1033,1036. Same unsuccessful results. I have no idea what to do next. It does appear that I can blank the Language field in the Upgrade Table via the Direct Editor.

Something is definitely amiss with this multi-language install. I may have to hit support up with this one.

[Reureu]

Hi there,

The funny thing in your log is that the custom action that logs your previous product as "not related" is ISSetAllUsers.

The Upgrade table is actually used by FindRelatedProducts which seems to do nothing if I believe your logfiles.

In your successful upgrade log:

MSI (c) (28:14) [09:34:53:734]: Doing action: FindRelatedProducts
Action 9:34:53: FindRelatedProducts. Searching for related applications
Action start 9:34:53: FindRelatedProducts.
FindRelatedProducts: Found application: {8E482393-8EBB-4C31-AD13-9EAF9873EC56}
MSI (c) (28:14) [09:34:53:734]: PROPERTY CHANGE: Adding ISFOUNDCURRENT property. Its value is '{8E482393-8EBB-4C31-AD13-9EAF9873EC56}'.
Action ended 9:34:53: FindRelatedProducts. Return value 1.

In your failed upgrade log:

MSI (c) (F8:CC) [09:48:56:875]: Doing action: FindRelatedProducts
Action 9:48:56: FindRelatedProducts. Searching for related applications
Action start 9:48:56: FindRelatedProducts.
Action ended 9:48:56: FindRelatedProducts. Return value 1.

So if I were you, I would try to understand why the FindRelatedProducts action does not work.

Could you have installed 10.0.1 using the per-user installation context?

[Superfreak3]

Reureu wrote:
Could you have installed 10.0.1 using the per-user installation context?

I don't believe so. The only difference between the 10.0.1 and 10.0.257 installs was the changing of codes, etc to prep the later as a Major Upgrade.

ALLUSERS is authored into the Property Table with a value of 1 and the user for this install testing is an Admin so it should be executed in Machine context in all instances.

I still think it has something to do with the Language setting in the Upgrade table. If this is blanked the 10.0.1 to 10.0.257 upgrade works as expected. I will set up that test now and post the logs in a bit.

[Superfreak3]

In the interim, here is the support ticket info I submitted along with an attachment containing some upgrade setting images and logs. Maybe there are more clues in there...

I’m am preparing for a future release of our software, version 10, and I want to ensure that future upgrades of that release family are successful. This will be a localized version of our product offering English and French as the languages. All of our previous releases have been English. All releases were also compressed in a Setup.exe. v10 Is the first to offer the language selection dialog.

In testing with our current version, 8.6.x, there is no problem with the Major Upgrade. All is removed and the latest is installed. Currently the language setting in the Upgrades view is English. I have attached shots of the Upgrade Settings and an install log showing this upgrade to v10.0.1 (v8TOv10.0.1Settings_1033.png and v8TOv10.0.1_1033.log).

In looking at the log, it sees the previous version as related.

I now bump the ProductVersion to 10.0.257, change the ProductCode and PackageCode, and change the MaxVersion in the Upgrades view to 10.0.257 to enact a Major Upgrade from 10.0.1. Again, the only language in Upgrades is 1033, but v10 is set to support 1033,1036 (French). Engilsh was selected at install time. I’ve attached the screenshot of these settings and the log (v10.0.1TOv10.0.257Settings_1033.png and v10.0.1TOv10.0.257_1033.log). I am also left with two entries in Add Remove Programs. I cannot figure out why this upgrade is not occurring.

I then read that to cover all languages in the Upgrade table, the language field should be left blank. If I try this by extracting the .msi then running with a blank language field for the 10.0.257 upgrade, all works as planned. I did not log that installation.

There currently does not seem to be a way to leave this entry in the IDE blank as when you switch views and return to the Upgrades view, the default of 1033 is now visible. Is there a way to wildcard this entry to cover all languages? I do think I can make it work buy clearing the field value in the Direct Editor, but I don’t understand why I have to do this now for the v10 family. The only real difference is that 10.0 will be our first release offering additional language support.

I then thought that maybe I have to include 1033,1036 in the Upgrades view language setting. In doing so for the v8 to 10.0.1 upgrade, the log indicates that the products now are not related, but it appears v8 is removed as expected and the Major Upgrade seems successful (v8TOv10.0.1Settings_1033_1036.png and v8TOv10.0.1_1033_1036.log).

After install of 10.0.1 and attempted upgrade to 10.0.257, it appears the detected language of 10.0.1 is 0 not 1033 as selected. I wonder if the Setup.exe is passing the language selection badly. The log and and screenshots are attached for this scenario as well (v10.0.1TOv10.0.257Settings_1033_1036.png and v10.0.1TOv10.0.257_1033_1036.log).

Again it seems to be related to the Language field in the Upgrade table because if I blank this field, the v10.0.1 to 10.0.257 appears to be successful. How am I to work around this in the IDE or what am I missing that is causing our latest Major Upgrade to fail resulting in two instances in Add/Remove Programs?

All above mentioned logs and images are attached in a .zip file.

Sorry for the confusing file names!!

[Superfreak3]

Here's another log for the 10.0.1 to 10.0.257 Major Upgrade. 10.0.1 was built with 1033 in the Language field of the Upgrade Table. I blanked that out via Direct Editor for the 10.0.257 build.

After doing this, the Major Upgrade to 10.0.257 worked as expected. I must have something set up incorrectly to handle multiple languages or something. Or, is the only workaround to blank the Language field in the Upgrade table to handle all languages?

Listing the languages specifically as outlined above does not work (1033,1036).

[Superfreak3]

To see if I'm missing any Upgrade Settings, I decided to test a v10 to v10 Major Upgrade by removing the second language offering. After removing the French language from the General Information area and the Release UI settings as well as setting the Language Selection dialog to No, the upgrade then worked as expected.

I also noticed that the .mst for the initial v10.0.1 install (with 2 languages) has or sets a template summary property with a value of x64;0,1033,1036. I'm wondering where the 0 is coming from or what that might indicate. I believe one of the logs in the MajorUpgradesInfo.zip file posted earlier shows the unsuccessful 10.0.1 to 10.0.257 upgrade and 0 is the detected language. Maybe that is the problem. ??

[Superfreak3]

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.

UPDATE: Adding the 0 to the Language field in the Upgrade Table allows the Major Upgrade to function as intended. Not sure if this is the best workaround. This has been escalated by IS Support.

[rittjc]

Please add this setting of the Language to 0 in the Update Table in order for upgrading to work.

I spent two days including a Saturday trying to debug what is happening that fails the detect and comparison of an older version thinking it was a newer version!

THANKS Superfreak! You are the freakiest!;)

[Superfreak3]

I believe blanking the Language of the upgrade record in question works as well and I might have stated that earlier, but I've tried so much tracking this down, that I could be mistaken.

This issue has been escalated at IS Support. Something is amiss.

[Reureu]

Actually, you could leave the Language column empty:
Here is what the MSI documentation states

http://msdn.microsoft.com/en-us/library/windows/desktop/aa372379%28v=vs.85%29.aspx

Language
The set of languages detected by FindRelatedProducts. Enter a list of numeric language identifiers (LANGID) separated by commas. Enter msidbUpgradeAttributesLanguagesExclusive in Attributes to detect all languages exclusive of those listed in Language. If Language is null or an empty string (""), FindRelatedProducts ignores msidbUpgradeAttributesLanguagesExclusive and detects all languages.

Attributes
This column contains bit flags specifying attributes of the Upgrade table.
...
msidbUpgradeAttributesLanguagesExclusive 1024 0x400 Detects all languages, excluding the languages listed in the Language column.

It might also be a good idea to check the attributes of your upgrade entry in this table, as it reverses the logic of the language detection.

[Superfreak3]

Reureu wrote:
It might also be a good idea to check the attributes of your upgrade entry in this table, as it reverses the logic of the language detection.

What do you mean by this?

Leaving the Language field blank in the Upgrade table causes the loss of ability to target certain languages. Currently it appears this ability is hindered by the addition of the 0 in the Template Summary Property at build time.

[Reureu]

I meant that the msidbUpgradeAttributesLanguagesExclusive flag excludes listed languages of your upgrade entry, instead of including them.

[Superfreak3]

That setting is currently set to No. I don't know if that is the cause of the 0 being added to the TSP or not, but the later is causing Major Upgrades to 'break'.

[Reureu]

You are right with that:

I don't know if that is the cause of the 0 being added to the TSP or not, but the later is causing Major Upgrades to 'break'.

It is described in the MSI documentation here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372070%28v=vs.85%29.aspx

Entering 0 (zero) in the language ID field of the Template Summary property, or leaving this field empty, indicates that the package is language neutral.

This 0 is probably inserted by InstallShield when building the MSI package.
I am still working with IS 2010, and this '0' is also inserted in my output package.

[Superfreak3]

After much back-and-forth, InstallShield now sees this as a bug that inhibits the ability to target certain languages with Major Upgrades.

I would think they should set the Language field of the Upgrade record based on the Exclude Specified Languages setting. If set to No, blank the language field for the particular upgrade record.

At any rate, place 0, with any other languages in the Language field or blank it as a workaround to allow Major Upgrades.