How to suppress message box during silent upgrade

[vishnupriya]

I actually wanted to do major upgrade of a product say ProA(from version 1.0 to 2.0),silently, suppressing any message box that may appear inbetween.I am using Basic MSI project.
The problem I am facing here is that: ProA of ver1.0 which is already installed on the pc has a CustomAction that is conditioned to display a message box during uninstallation. When doing major upgrade , to ver 2.0 silently,teh message box appears while ver1.0 is getting uninstalled. This is annoying our install flow, as we dont want any user intervention while major upgrade happens. The ver1.0 is already released and so we cant make changes in it.

Is there any way to suppress this message box while uninstallation, so major upgrade goes smoothly when launched silently?

Thanks in advance.

[Cary_R]

Hi Vishnu,

Do you know what the condition is on the custom action from the previous install? If it's something like:

REMOVE~="ALL"

Sometimes you're able to change this behavior by manually specifying the list of features in the Upgrade table of the new project (this will be done in Direct Editor). For reference:

http://msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx

If the custom action comes too late in the sequence (since REMOVE gets changed to ALL somewhere around CostFinalize during uninstall), the other option is to force a change to the cached MSI package using one of two methods:

1. Using Windows Installer API's to hack the cached MSI either by making record changes, or applying a transform. The latter needs to have a standalone executable written for this purpose, since you can't call these API's from a custom action *.dll.

The simpler approach here I think would be to invoke wirunsql.vbs to run a simple SQL query against the cached MSI package. Then the code you have to write basically comes down to a call to MsiGetProductInfo() to get the location of the cached package under C:\Windows\Installer\

2. Generate a small update patch that conditions out the custom action, and then run the *.msp file from the UI sequence of the new package. While not the cleanest approach, this is probably the easier way to handle it.

Hope this helps point you in the right direction.

--Cary

[vishnupriya]

Hi Cary,

Thanks for your suggestions.

I have use the condition REMOVE="ALL"

I tried the first workaround of updating the entries in the Upgrade Table through direct editor. But the problem I have facing is that it now leads to two entries of the same product to exist on teh Add/remove programs:(
So could not follow the first approach.

Coming to the other 2 workarounds: by updating the cached MSI by applying transforms or by giving a patch before the actual upgrade, looks fine, but the problem is that it complicates things. My goodness, the custom action we wrote throws this error only if a particular condition (getting reference to virtual dir) fails.
So we have decided here to create dummy virtual dir before the REmove Existing products Custom action exists so that this message wont be thrown
or even re-order the unisntallation of the msis(we have actually a sequence of msis aand this message box gets prompted only when uninstalled in order same as the installm order of msis).
So the approach we selected is: uninstallation of older msi followed by installation of newer msi (in a particular order)instead of going for MAjor upgrade(which internally does the same- but promts msg box due to dependency on other external msis)

Hope this seems to be acceptable workaround!:)