Major Upgrade removing files/Not installing required Files

[Tim_Mayert]

Now this has probably been mentioned here before, but I could not find an exact match to my issue or solution. So I figure that I would just create my own issue here and see if anyone has a solution to this problem.

We have been seeing this issue for a while now and it is always the case where the install is doing a major upgrade over a previous version of our product and in some cases there were components that had higher version numbers in the previous version then what was in the new version.

What happens is that the msi install detects the previous version and it detects that some of the component version numbers are higher than what is in the install. So it turns off these components so that they do not install, as older files should not overwrite newer files, but then the install goes ahead and uninstalls the previous version, including the files with the newer versions, and then completes the install of the new version, excluding the ones that the msi marked as not needed to be installed.

Once done the files that had higher version number are gone and therefore the app will not work as there are now missing files. The user would then have to perform a repair of the install to have the files get installed.

I was trying to find any microsoft articals on this and found this one: http://support.microsoft.com/kb/905238

But the problem with their solution is that it will only work with components that all have their Shared flag set. This is like setting your major upgrade to install first and the perform the uninstall of the previous version, but all files have to have the Shared flag set.

In our case the files in the main App folder are not shared and therefore does not have the Shared flag set, and all our custom merge modules are shared and therefore have the Shared flag set. If we set out RemoveExistingApps to be triggered after InstallFinalize then the shared apps would be fine, but the main app files will be removed.

Is there any other solutions to this issue? Is there a better way of handling this or does any of the newer versions of InstallShield or MSI engines solve for this issue?

[Alibaba]

I have the same problem with my Setups. But since there are still no answers it seems to be impossible to handle this with InstallShield generated Setups.

[Jeff2008]

We had the same problem with our setups. In our case, we could fix the problem by using the "always overwrite" property, but that's because they were not shared.

[TonyLowrey]

The stark fact is that a Major Upgrade where the uninstall happens before the install (RemoveExistingProducts is early rather than late) is not the same as doing an uninstall followed by an install of the products being upgraded. The problems occur with SXS and GAC assemblies which are not properly evaluated for uninstall/install and so may be left uninstalled after the upgrade. The upgrade has to be repaired to get everything back (with fingers crossed!).
I still have not had a proper solution from anyone but I guess there is no proper solution to an MSI deficiency!

[sjimmerson]

We ran into the issue in http://support.microsoft.com/kb/905238 and ultimately decided to install a private copy of the assembly in the application's installation directory instead of installing it to the GAC. I have never run into this issue with files installed anywhere else.

[Ron_Schaeffer]

I think there are actually two issues raised in Tim's original post - one related to file versioning and one related to GAC (i.e., MS KB 905238).

In regards file versioning - I have just been in a situation where I had to move some functionality / assemblies from one 'product' to another, with the result that the go-forward product (a newer product) had a lower major.minor.build versioning than the original product. As a result, the old assemblies were not replaced with the new ones exactly because of what Tim originally described (i.e., new file versions less than old versions, so new files disallowed for delivery, but upgrade correctly 'uninstalls' the prior product version) - even when I tried changing the Component GUIDs. I too have been unable to find a solution to this issue - except to separately pre-uninstall the original product, or to repair after an upgrade install.

In regards GAC (MS KB 905238) - this seems to me to be a much larger, more involved issue. Our developers are moving to a GAC implementation model, so I am just starting to investigate GAC installations, and the more I see the more concerned I get! And I tend to agree with TonyLowrey that this is an MSI deficiency.

Has anyone successfully implemented a GAC targeted product which upgrades from one version to the next? If so: How did you deal with the issues indicated in MS KB 905238? Each build/release, did you have to revise version info for every file in the Installer going to the GAC? How did you produce a patch for your GAC delivered files (specifically, we use QuickPatch)?

[cbarlow]

I keep running into this issue as well-- running a major upgrade that leaves files out because they are marked as disallowed before the installer knows everything will be uninstalled.

I wonder if there's a way to change the file key while keeping the filename the same. Windows installer documentation says "If the installer finds a file with the same name as the component's key file installed on the target location, it compares the version, date, and language of the two key files and uses file versioning rules to determine whether to install the component provided by the package." If I could change the key file, and keep the filename the same, wouldn't that let me bypass the comparison? I don't know much about key files, but the logic makes sense to me. Does anyone know if this is possible or how to do it?

Clark

[cbarlow]

I just tested my theory and it didn't work. I changed the key file by adding a duplicate component so that the default key file would get changed to Program.exe1 as opposed to Program.exe. I still ended up with the same problem as before.

[Poltron]

Hi,

We had a similiar problem, but not exactly what the OP mentioned.

On a major upgrade, the required vc8 runtimes (and other Winsxs friends) were not upgrading. We now have a solution that has been working well over our last few releases:

Basically, we are abandoning the minor/major upgrade functionality of msi and using the power of commandline msiexec to uninstall the previous product if it's detected. Here we go:

instructions done in IS 2008 / Basic MSI

1. Create a new Media\Upgrades entry:
I called ours MajorUpgradeDetection
upgrade code: {00000000-0000-0000-0000-000000000000}
min ver
include min ver: no
max ver:
Include Max ver: no
Language:
Exclude specifc langs: No
Detect Only: YES
Detect Prop (ours is still set to): ISACTIONPROP3
Only remove ..:
Continue on failure: no
migrate feature states: (probably should be no): yes

2. create custom action
MSI Type Number: 98
ours is named: UnInstallPreviousVersion
working folder: SystemFolder
Filename and command (ISACTIONPROP3 contains the GUID of previous product that was detected): msiexec.exe /x[ISACTIONPROP3] /qb /passive
return proc: synch (ignore)
in-script exec: Immediate exec
Execution Scheduling: Always execute
(all are "absent from sequence")

3. Onto the User Interface\dialogs...
ReadyToInstall dialog's behavior link..
Click InstallNow control
Add a new event as follows:
event: Do Action - Argument: UnInstallPreviousVersion - Condition: ISACTIONPROP3

The downside of this method is that it only works in the UI sequence (will not work in silent installs). You can change this, but our company had a requirement to display the version dialog to user as well as a warning that thier previous version would be removed. For directions on the warning message to users.. here it is:

On User Interface\Dialogs\InstallWelcome dialog:

a. Create a text box with the text you want to display if a major upgrade will be performed, .. ours is named "MajorUpgradeWarning".
b. Navigate to this dialogs behavior page... then click the 'conditions' tab at the bottom of the screen. Click on MajorUpgradeWarning
c. We have a Show action with ISACTIONPROP3
d. We also have a hide action: Not ISACTIONPROP3

As I mentioned, this only works in the UI sequence, not silent installs. So we then had a requirement to block major upgrades during silent installs....
a. Navigate to Behavior and Logic\Custom Actions
b. I created a MSI Type Number 19 action as follows:
We named it: SILENT_INSTALL_ABORT_ON_MAJOR_UPGRADE
Error Msg (Probably should be translated text though): "A version of this software is already installed, please uninstall before attempting a silent install."
Return Proc: sync (check exit code)
In-Script: Immediate Exec
Execut Scheduling: always execute
Install Exec Sequence: After ISPreventDowngrade (if you dont' have that,.. it's basically after the "FindRelatedProducts" CA)
Exec condition: ISACTIONPROP3 And UILevel=2

[wiggers]

I've discovered that replacing the Windows Installer with the v2 one solves this problem:

http://www.microsoft.com/downloads/details.aspx?FamilyId=889482FC-5F56-4A38-B838-DE776FD4138C&displaylang=en&displaylang=en

Of course, there's no mention in the KB article anywhere that this does fix it!

[wiggers]

I've discovered it only partially solves the problem. Now had to advise users to keep the installation CD in the drive when they first start using the product, so the installation can repair itself.

Thank you MS!