Repair popup - how to get rid of it?

[Scott_Mayham]

Problem: The MSI Repair/Remove dialog pops up during patching. How do I get rid of it?

System: a VM running W2008 R2. Varying the UAC settings from high to low has no effect.

Before purchasing InstallShield, our developers created product MSIs directly from .NET. Now I need to use IS 20011 Pro to generate a patch for one of the already-created MSIs which is "in the wild". The developers fixed a couple of files, and generated a new build with a new MSI. I used InstallShield to create a patch (small update) project, and when applied, I get the annoying "repair" popup from Windows Installer (attached). It's as if it thinks I'm damaging the original installation. Selecting "Repair" and clicking "Finish" results in the patch being applied as desired.

I get no errors from the InstallShield build of the patch. The verbose log offers no clue (at least not to me). Available upon request.

Clearly I am missing something. What I'm NOT missing:
Upgrade Code in Patch = Upgrade code from original MSI
Product Code in Patch = Product Code from original MSI
Product Version in Patch = Product Version of Original MSI

I'm stumped. Anyone got any ideas or suggestions?

Thanks

[MSIYER]

Please attach the verbose log of Windows Installer.

[Scott_Mayham]

See the Verbose log, attached.

regards,

[MSIYER]

This behaviour is appropriate as patching is essentially repairing the application using transforms. The log was required to diagnose any other issues. I have no idea of how Visual Studio creates packages. Conditions enforced on dialogs in VS are not known to me.

In Installshield the default conditional expression enforced on maintenance dialog is "Installed And Not RESUME And Not Preselected And Not PATCH".
This means:
The maintenance dialog will not pop-up during pathch install.

Thus installation packages created with Installshield will not cause this trouble.

Since your installation is already in the wild, you cannot modify the UI sequence as the cached msi file is used during the maintenance.

Try using the silent mode flags for patch installation and post the results.

[Scott_Mayham]

Since I began this thread, I took the time to more carefully examine the log. And, from the log it is clear the the Base MSI has a UI action MaintenanceForm (the one in the screenshot). Looking at the Base MSI with ORCA reveals that it does have a condition on it - Installed<>"". Clearly that does not consider patching, as you have suggested. And, as you also have suggested, the UI is popping up exactly as (poorly) designed. Pretty much end of story.

I now need to dig into VisualStudio's packaging, to see if there is some way to solve the problem at the source.

Thanks for looking into this for me.

Regards,

[Scott_Mayham]

"silent mode flags?" Huh?

[Scott_Mayham]

Our Base MSI Installers are produced by VisualStudio 2010. Unlike InstallShield, VS does not produce "Patch-Friendly" Installers. In this particular case, the Base Installer created by VS has a StandardAction "MaintenanceForm" in the InstallUISequence which has the Condition set to

Installed<>"".

In other words, run this action if the product is installed, don't run it if it is not yet installed. For this to be Patch-Friendly, the condition should be

Installed<>"" And NOT PATCH

So, when patching, the MaintenanceForm action runs, and you get its unwanted UI. There appears to be nothing I can do about it, since the problem is in the MSI which is already installed on the customer's system.

However, I am writing a VBScript to add the "And NOT PATCH" to the condition as a post-build action in the VS build. So, going forward, Base installers won't have this problem.

I see this as an interim solution. Does anyone know how to modify Visual Studio's MSI-producing behavior?

Regards,

[MSIYER]

I feel I was wrong when I said that the base cached msi will be used during patch install. Your post made me dig further and it seems that the base cached msi is modified at runtime by the Windows Installer engine prior to the display of dialogs. That means, if you make proper changes in the newer version of your msi, i.e., add the proper condition to the dialog "NOT PATCH" etc... and then go on to create the patch, the UI changes should reflect during the patch install.

The transforms in the patch are applied to cached msi prior to the display of patch installation UI.

Please follow the following link:
http://www.softsummit.com/library/white_papers/installshieldpress_ch12.pdf

This link has all details you would need to work out of your situation:
http://email.softmart.com/itadvisor/docs/I...hing_Sept08.pdf

Read the whole thing carefully.

I apologise for the mistake.

[Scott_Mayham]

MSIYER,

(I saw your parallel reply on InstallSite, and answered it there).

You provided two links, but the one to summitsoft does not work ("can't find the document" message - could be our corporate firewall), and the one to the White Paper by Robert Dickau I already have and have read.

The thrust of Dickau's paper is how to make the base MSI patch-friendly, which, while important to know, does not really help me in my present situation, since I am attempting to patch MSIs which were built by VisualStudio without Dickau's suggestions in mind.

I've never tried such a thing - is it possble for a patch to contain a new CA which doctors the conditions on a UI in the base MSI, and which runs very early in the UI sequence? Since at run time, what is executing is really the merged/transformed/patched MSI built on the fly by the Windows Installer, it seems like this MIGHT work. Are there some restrictions I'm ignorant of?

Regards,