eelou
asked on
Installshield nested installer question
InstallShield 2010 professional. While running a BASIC MSI installer, I tried to uninstall a different product using a custom action "New EXE\Path referencing a directory", c++ function.
The function was called and gave a message "Another program is being installed. Please wait and try again". I had tried "New nested MSI, but had gotten similiar messages".
Yet, I can call a custom action that calls a VBscript...and it works...
Set WshShell = CreateObject("WScript.Shel
WshShell.Run "msiexec /x {xxx-xxx-xxx} /qn"
Why does one not work, and the other does?
If you have an example that works through the nested CA, or c++, please give example. thanks.
The function was called and gave a message "Another program is being installed. Please wait and try again". I had tried "New nested MSI, but had gotten similiar messages".
Yet, I can call a custom action that calls a VBscript...and it works...
Set WshShell = CreateObject("WScript.Shel
WshShell.Run "msiexec /x {xxx-xxx-xxx} /qn"
Why does one not work, and the other does?
If you have an example that works through the nested CA, or c++, please give example. thanks.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
vadimrapp1: I want to uninstall X, not upgrade it when I install or upgrade Y.
CSI_Windows.com: The C++ CA is 'deferred in system context', so it is after installinitialize. I am not sure what you meant by "MSI prevents two packages from being past that point action at the same time." Why is "New nested MSI" still listed as a CA, if it is depreciated? As far as chaining, some of the previous versions of the product are installed on XP and 2003, and I do not think that we can ask the customers to install Windows Installer 4.5.
No one has answered by the VBscript works. Is it because it is outside of the purview of InstallShield?
CSI_Windows.com: The C++ CA is 'deferred in system context', so it is after installinitialize. I am not sure what you meant by "MSI prevents two packages from being past that point action at the same time." Why is "New nested MSI" still listed as a CA, if it is depreciated? As far as chaining, some of the previous versions of the product are installed on XP and 2003, and I do not think that we can ask the customers to install Windows Installer 4.5.
No one has answered by the VBscript works. Is it because it is outside of the purview of InstallShield?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Interesting stuff. I do not have access to work from home. I will try this tomorrow.
> I want to uninstall X, not upgrade it when I install or upgrade Y.
If you specify in Y that it upgrades X, then X will be uninstalled.
> No one has answered by the VBscript works.
CSI-Windows did: "Most likely you have sequenced the vbscript CA before InstallInitialize?"
Installation goes through 2 major phases: user interface, when the user works with the dialogs, and the actual execution, which begins with InstallInitialize and ends with InstallFinalize. It's only the latter that can't run in more than one installation at a time in the system. So if you placed your vbscript action elsewhere (either before InstallInitialize, or after InstallFinalize), then it wouldn't interfere.
Regarding CSI-Windows' recommendation to make sure that X is uninstalled before Y starts installing - it's if this is what you actually want. The opposite, when you want to uninstall X only if Y has succeeded, but leave X in place if Y failed, is quite possible scenario - you have to decide. Example: the users have Adobe Reader installed; you decide to replace it by Foxit Reader. If installation of Foxit fails, you don't want the users to be left without either.
If you specify in Y that it upgrades X, then X will be uninstalled.
> No one has answered by the VBscript works.
CSI-Windows did: "Most likely you have sequenced the vbscript CA before InstallInitialize?"
Installation goes through 2 major phases: user interface, when the user works with the dialogs, and the actual execution, which begins with InstallInitialize and ends with InstallFinalize. It's only the latter that can't run in more than one installation at a time in the system. So if you placed your vbscript action elsewhere (either before InstallInitialize, or after InstallFinalize), then it wouldn't interfere.
Regarding CSI-Windows' recommendation to make sure that X is uninstalled before Y starts installing - it's if this is what you actually want. The opposite, when you want to uninstall X only if Y has succeeded, but leave X in place if Y failed, is quite possible scenario - you have to decide. Example: the users have Adobe Reader installed; you decide to replace it by Foxit Reader. If installation of Foxit fails, you don't want the users to be left without either.
ASKER
As you can see from the attachment, the vbscript call is right after installinitialize (the same place that the C++ Ca was). The Vbscript does do the uninstall, the C++ CA does not.
I tried the Upgrade table fix that you mentioned, and I do not seem to be able to get that to work either. In the attachment, there is a screen dump of the Upgrade table, and the log output that shows that there was a "related" find, yet the X product does not uninstall.
Uninstall.docx
I tried the Upgrade table fix that you mentioned, and I do not seem to be able to get that to work either. In the attachment, there is a screen dump of the Upgrade table, and the log output that shows that there was a "related" find, yet the X product does not uninstall.
Uninstall.docx
For #2 check if you have RemoveExistingProducts in InstallExecuteSequence.
You didn't have your VBS uninstall CA enabled on the same log where you found the upgrade table didn't remove the product right? (Sorry to ask - I know I can do this kind of thing too ;).
Would be best to zip and upload logs of both scenarios.
You didn't have your VBS uninstall CA enabled on the same log where you found the upgrade table didn't remove the product right? (Sorry to ask - I know I can do this kind of thing too ;).
Would be best to zip and upload logs of both scenarios.
ASKER
I do not have those logs anymore. This is the VB code...
Set WshShell = CreateObject("WScript.Shel
WshShell.Run "msiexec /x {8B8FFF9E-AD55-4324-8E42-6
Like I said, the VB code does the job, the c++ (in the same sequence location), does not (I have tried both CreateProcess and shellExecute). I understand what was said about not being able to do two rollback loggings at the same time, it must be that the VBscript shell is not under the control of InstallShield, and that must be why it works (???).
I went back to the Upgrade table, and finally did figure it out (see attached). The row with the attribute of 4, does not check for any versions, and does the uninstall. The row with the attribute of 256 uninstalls any version that starts with the value in the version min column.
I will wait to see if you have any furthur comments, and then will split the points between the both of you.
Uninstall2.docx
Set WshShell = CreateObject("WScript.Shel
WshShell.Run "msiexec /x {8B8FFF9E-AD55-4324-8E42-6
Like I said, the VB code does the job, the c++ (in the same sequence location), does not (I have tried both CreateProcess and shellExecute). I understand what was said about not being able to do two rollback loggings at the same time, it must be that the VBscript shell is not under the control of InstallShield, and that must be why it works (???).
I went back to the Upgrade table, and finally did figure it out (see attached). The row with the attribute of 4, does not check for any versions, and does the uninstall. The row with the attribute of 256 uninstalls any version that starts with the value in the version min column.
I will wait to see if you have any furthur comments, and then will split the points between the both of you.
Uninstall2.docx
Hmmmm.... It would take several logs - including both internal uninstall attempts to unravel this.
There is a level of execution blocking that is a function of MSI, not InstallShield or any other authoring tool.
Did you write the C++? Is it using the equivalent of msiexec /x <PRODUCTCODE>?
There may be an exemption for uninstalling by product code since that is what MSI would do internally when using the upgrade table.
Perhaps referencing the .MSI package would trigger the blocking.
Very interesting - don't have time to put it under the microscope.
There is a level of execution blocking that is a function of MSI, not InstallShield or any other authoring tool.
Did you write the C++? Is it using the equivalent of msiexec /x <PRODUCTCODE>?
There may be an exemption for uninstalling by product code since that is what MSI would do internally when using the upgrade table.
Perhaps referencing the .MSI package would trigger the blocking.
Very interesting - don't have time to put it under the microscope.
I would run ProcessMonitor, and watch how c++ and vbscript create msiexec process. It's quite likely there's difference in credentials / impersonation, and if so, then there's high probability that it's the entry into yet another Installer's either bug, or undocumented feature related to impersonation.
Regarding non-uninstalling related product, even after it's found - have you removed custom actions related to the nested installation?
Regarding non-uninstalling related product, even after it's found - have you removed custom actions related to the nested installation?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
MSI prevents two packages from being past that point action at the same time.
Nested installs are depreciated: http://msdn.microsoft.com/en-us/library/aa368010(VS.85).aspx
If you need to chain multiple MSI together, you can use chaining - the main feature of the 4.5 release: http://msdn.microsoft.com/en-us/library/bb736322(v=vs.85)