This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Repair popup - how to get rid of it?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 06, 2011
03:07 PM
Repair popup - how to get rid of it?
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
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
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 07, 2011
02:29 AM
Please attach the verbose log of Windows Installer.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 08, 2011
03:13 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 12, 2011
01:50 PM
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,
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,
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 12, 2011
01:52 PM
"silent mode flags?" Huh?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 15, 2011
08:43 AM
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,
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,
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2011
02:54 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2011
09:20 AM
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,
(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,
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)