msi - Upgrades quit working when added new components

[rslangham]

Minor Upgrades have been working for awhile, then I added a new directory and some files to the installation, and then the upgrade quit working between version before the files added to the version with the new files.

If I do a clean install with a version with the new files, and then do an upgrade with a new version of this install, then the upgrade works fine. Same as upgrade before I added the new files. Seems that adding the new dir and files to the install breaks the upgrade.

The user is prompted that they will be upgraded and the Setup.exe automatically calls the msiexec with the standard command line params...

REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1

It goes through the install just like it is doing the upgrade with no errors, etc. All looks ok, but if you go and look at the files nothing (not even updates to pre-existing files) got installed!!!!

UpgradeCode is the same
PackageCode is different
ProductCode - ProductCode is the same, but have also
tried changing the ProductCode and doing major upgrade instead
ProductVersion is incremented
I have UpgradeEntry with ...
GUID, Version=1.0.0.0000 Version=blank Attrib=769, ISACTIONPROP1

I have tried numerous different scenarios playing around with these values and just can't get the upgrade to work!

It is on Windows 2003 Server 64-bit if this matters.

Ron

[RobertDickau]

Does InstallShield's build-time upgrade validation tell you anything?

If you haven't yet, please see the MSI help topic "Changing the Product Code" for information about project changes that require a major upgrade instead of a minor upgrade.

[rslangham]

This does give some useful information.

First, on the MSI file I get the log...

Message: The product version '3.0.0.599' differs from the product version '3.0.0.570' but only past the third element. The Windows Installer does not detect version differences past the third version element.

We have always been just incrementing this version and have not had a problem until now.

On some of the other files...

Validator: Val0006
Severity: Error
Message: The Component '_03C02B258CBAEC50C5DF634E945AB56C' identified by ComponentID '{03C02B25-58CB-AEC5-0C5D-F634E945AB56}' is missing from the newest version of your setup. You can not delete components and still do a minor/small upgrade. You must perform a major upgrade.
Ref. Pkg: \\rlangham01\share\install64bit\570\cerion application server.msi

I have tried patching the ProductCode in the MSI file to a new unique value and this didn't work either.

Let me try a couple of things..

Ron

[RobertDickau]

The three-field ProductVersion warning is important to keep in mind for major upgrades.

As for the warning you're seeing, if you're using dynamic file linking, you'll want to look into using the "Patch Optimization" (previous package) setting in the Release Wizard to ensure keys in the File, Component, and Media tables match up between builds...

[rslangham]

Fixed the problem. I had to resort to doing major upgrades all the time for all installs. So, minor upgrades work ok as long as you are just upgrading the same files, but if a new file or directory is added then looks like you have to resort to major upgrades. Since not wanting to have to keep track of this for each release, nor do we really know which version our customer is upgrading from, we have to do Major upgrades for all releases.

I am going to give a few details here to hopefully help other people who may have this problem. I have been working on this issue for over a week. Not sure why ugprades have to be so hard, it should "just work" intstead of having to do this fine tuning of minor and major upgrades, etc.

In previous InstallShield 11.5 Express, we always did major upgrades in order to avoid the user being prompted to uninstall first or having to pass special command line params to Setup or MsiExec. We handle this by post-patching the MSI file (we used automated builds), set our version number and assigning a new GUID to ProductCode. Unfortunately, this also took a long time to determine the proper process for upgrades to work reliably.

We recently upgraded to InstallShield 2008 and the nightmare of upgrades came back. Modifying the MSI no longer worked. Discovered in new InstallShield that some additional smarts have been put in to help with this upgrade issue. The Setup.exe now has the ProductVersion embedded in it and it does its own comparison to the registry without inspecting the MSI to determine if upgrade needed. If upgrade is detected, then the proper params are passed to MSIEXEC to do the upgrade. Therefore, the first fix in the upgrade issue was to use the NEW IsCmdBld command line -y option to set the product version, this sets it in both the Setup.exe and MSI. If you patch the MSI, it won't work because the Setup.exe's internal version number is different than the MSI version.

This all worked fine until recently added some more files to the install and then upgrades broke again. (thus this thread). In my testing of major upgrades of patching the ProductCode, upgrades did not work with new InstallShield. It would work only under some circumstances.

Finally tracked it down that you must now set the ProductCode using the IsCmdBld -z command line parameter. Of course, you can set in the InstallShield IDE, but all of our builds are automated and done through command line. If you do this, then major upgrades start working again. So, can no longer post patch the MSI (which was the only option with pre-InstallShield 2008). Consult the help for the -z parameter, if you do IsCmdBld /? it doesn't give help on this parameter. For some reason, upgrades behave differently if you patch the MSI with a new product code than if you specify via the IDE or command line. I am guessing that Setup.exe may also keep this value internally in its EXE and uses it to determine if minor or major upgrade.

I would think to avoid other mysteries like this, that possibly Setup.exe should not have redundant information embedded in it that also resides in the MSI, instead it should read the MSI at runtime and extract the values it needs.

[#6]

To me, it sounds like you could've authored the previous package setting in the ISM project file to point to your previous release. You're using dynamic file linking in your project and what's happening is that files are brought in with differing component codes versus the previous release. If you had authored that setting, you likely could have used the minor upgrades instead of having to resort to the major upgrade method.

Also, Express supports major upgrades via the Upgrades view in the IDE. It allows you to create & set up major upgrades automatically.

I am guessing that Setup.exe may also keep this value internally in its EXE and uses it to determine if minor or major upgrade.

This is correct and is necessary to avoid having end-users being required to pass minor upgrade parameters. ProductCode is a private property as well, so cannot be set through the command line.

A major upgrade is defined by changing the product code, package code, and authoring an upgrade table item for the upgrade. A minor upgrade only requires a change in package code. Both require that you change the product version. Small updates only require the package code but not the version.

I don't think you would ever have to post-build modify the MSI package in your situation. Likely leveraging the automation interface to do your builds would provide sufficient control and still have InstallShield taking care of all the inner workings for you.

http://helpnet.macrovision.com/Robo/BIN/Robo.dll?tpc=/robo/projects/installshield14helplib/IHelpAutomation.htm

[rslangham]

We do not want to have to refer to a previous package in order for upgrade to work. I notice that in InstallShield 2008 that to do a minor upgrade you have to specify this. This I suppose would fail if a user upgraded and skipped a few versions in between. e.g. did 1.1 -> 1.5 while 1.2 -> 1.3 was required to be major upgrade, while all other upgrades were minor.

We are not doing dynamic linking.

I had the major upgrade entry in the InstallShield express, but this didn't really appear to work unless the proper parameters were passed to MSIEXEC. We don't want to impose this on a user, they should simply be able to install new package and it will just upgrade it. This has been partially fixed with new 2008 version with the Setup now determining this and passing the proper params. But, it didn't seem to handle the case where they were upgrading and skipping several versions (some major and some minor) as I give above. So, so far seems that we just need to go with major all the time to handle all upgrade cases.

Without the patch to the MSI in previous InstallShield, the user was prompted that they would have to uninstall previous package before installing (not a good option for our users), or they would have to pass the proper params to MSIEXEC (not good option either, too techy).