All the tables can be viewed and edited in Additional Tools (last folder in left pane) - Direct Editor view. ... View more

There are three different placements for the RemoveExistingProducts action. It seems that you selected the placement where this action is sequenced after InstallFinalize action. In this situation a problem during the removal of the old product will not cause the new one to uninstall. Please see the Microsoft reference stating this: RemoveExistingProducts Action http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx Note, that you can instead sequence the action right before InstallFinalize to get full rollback coverage. In InstallShield this can be done in the Upgrades view - Major Upgrade Settings. Select the second radio button (Install setup then remove unneeded files) and the checkbox (Rollback all changes if removal of old files failed). Common Tab http://helpnet.flexerasoftware.com/robo/projects/installshield16helplib/UpgradeWISetupCommon.htm ... View more

Thank you for the follow-up post. Please take a look at the following help documentation: Specifying the Signature for a Managed Method in an Assembly Custom Action http://helpnet.flexerasoftware.com/robo/projects/installshield16helplib/ManagedCA-Arguments.htm Notice the following bit: "Note that if you use a custom signature, the custom action’s return value is not passed to Windows Installer. However, if the managed code throws an unhandled exception, the custom action returns ERROR_INSTALL_FAILURE to Windows Installer. Therefore, in order for the custom action to indicate failure and for Windows Installer abort the installation, the managed code must throw an unhandled exception." Regards, Ajay ... View more

I am guessing that you need to return ERROR_INSTALL_FAILURE instead of IDABORT to cause the install to abort. ERROR_INSTALL_FAILURE is used as the return code from MSI C++ DLLs. It is defined in msi.h to have a value of 1603. Reference: Custom Action Return Values http://msdn.microsoft.com/en-us/library/aa368072(VS.85).aspx ... View more

Hi Kiran, The easiest thing to do would be to show your message box when the user hits the Finish button on the SetupCompleteSuccess dialog (final success dialog). If this does not meet your requirements, and instead you have to have a message box displayed immediately when SetupCompleteSuccess dialog is displayed, then you can look into trying a more advanced technique: Create the custom action that displays the message box and give it a sequence number of -1 in the InstallUISequence table. This will cause MSI to run your custom action upon successful installation instead of displaying the SetupCompleteSuccess dialog. So you will have to launch the dialog from your custom action using MsiDoAction or equivalent API call. This approach does complicate your install, and it may be considered against best practice, but it does seem to work without issues. -Ajay ... View more

You can remove the install/launch condition that is checking for a pending system reboot from the General Information view. You can do this when editing an ISM or MSI file. Reference: MsiSystemRebootPending Property http://msdn.microsoft.com/en-us/library/aa370492(v=VS.85).aspx ... View more

I don't think you should be seeing ICE errors with regards to ShowMsiLog. This is a simple custom action that is included in the new Basic MSI project template in InstallShield. It's purpose is to display the MSI log file on MSI 4.0 and newer systems where logging was turned on. It does this when a checkbox on the final dialog is selected by the user to view the log. I suggest that you create a new basic msi project and build it with one file included to see if this is a problem in the sample MSI file. It should not be. If it isn't a problem, then you can take a look at the differences between your main ISM and sample ISM by searching through the direct editor for ShowMsiLog. ... View more

To get more familiar with conditions, please read the following help topic: Conditional Statement Syntax http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx An example of a condition that you can use to prevent your custom action from running during any maintenance operation is 'Not Installed'. Or if you wanted to only prevent the custom action from running during an uninstall, then you could use 'REMOVE="ALL".' ... View more

Hi Mahendra, Please see the following help article as reference: Capturing Virtualization Context http://helpnet.flexerasoftware.com/robo/projects/adminstudio95/ashelplibrary/isrcapturecontext.htm The context MSI contains the metadata registry and files that Windows Installer creates to manage installations - it isn't any actual application data. Since most applications don't really care how they were installed, this context data isn't usually necessary for the application to function. But it is possible for the application to search for one of its files by doing a MSI API query based on a component code of that file. In this situation the API call would fail unless the original MSI metadata is also put down by the context MSI. The basic idea is that you should only repackage a MSI if you are interested in converting it to a virtual package. In this situation Repackager will combine the information in the main MSI with the context MSI to create the virtual package. If you are repackaging to convert legacy packages into MSI packages, then you can ignore the context ISM/MSIs. ... View more

You should be able to use the ISWiFeatures collection off of ISWiProject to get a collection of the existing features. Then you can get the object pertaining to the feature you are looking for from this collection. Reference: http://helpnet.flexerasoftware.com/robo/projects/installshield16helplib/IHelpAutoISWiFeature.htm ... View more

Yes, it will be necessary to use a custom action to stop or kill running programs, otherwise a reboot may be required at the end. The functionality you pointed to for services is actually provided by Windows Installer through the ServiceControl table. ... View more

Windows Installer supports small, minor, and major upgrades. Of these only major upgrade actually performs an uninstallation of previously installed versions. And major upgrade requires changing the ProductCode, and also the uninstall of the previous version does not happen at the very beginning, but takes place after UI is shown and right before the new setup is actually installed. So it seems that with your restrictions in mind, you will need to issue a command to uninstall the previous MSI package, and then a separate command to install your new package. If you are using some kind of deployment mechanism, then perhaps it supports uninstalling MSI packages. ... View more

I think the Behavior and Logic - Support Files - Advanced Files - Disk1 view may meet your needs. You can add a folder structure there, and it will be copied directly to the Disk1 folder at build time. ... View more

Here are some troubleshooting ideas that should help to diagnose this problem further: 1. Try putting in some default values in the ComboBox table as a test. This will verify that the ComboBox items show up correctly as long as the table is populated. If the default values don't show up, then the problem may be that the height of the ComboBox is not big enough. 2. Put in some msgbox calls in your vbscript to verify that it does find the website information when running in a custom action in your MSI (I know you have verified it outside of the MSI, but this is just a sanity check). 3. Maybe try testing your MSI by launching msiexec from an elevated command prompt or by turning UAC off. -Ajay ... View more