• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1919
  • Last Modified:

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.Shell")
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.
0
eelou
Asked:
eelou
  • 4
  • 4
  • 4
3 Solutions
 
CSI-Windows_comCommented:
Most likely you have sequenced the vbscript CA before InstallInitialize?  

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)
0
 
Vadim RappCommented:
If your objective is to have working solution, then the easiest way to achieve what you want (remove installation X when you install Y) is to specify X in the upgrade information of Y. I.e. Y will upgrade X.

If your objective is in finding out why and how Installer worked the way you saw,  let us know.
0
 
eelouAuthor Commented:
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?
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
CSI-Windows_comCommented:
You answered where the C++ CA is defined, but not where the VBScript one was setup - it is the one succeeding, so would be the one sequenced before InstallInitialize.

Depreciated means "please don't use this anymore, it's not a good idea" - it does not mean "we removed the ability to do this from Windows Installer"

It is MSI that places a marker in the registry when an MSI has passed the InstallInitialize action - this is when the rollback logging starts and MSI cannot maintain two rollback logs simultaneously (besides many other reasons that running simultaneous installs are not a good idea).

vadimrapp1 is correct that adding the other product as an upgrade will uninstall the oter package.  Since they are unrelated products I would further advise you make sure the standard action "RemoveExistingProducts" is also between InstallValidate and InstallInitialize to remove the other product before starting your install.  This is documented at: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).aspx
0
 
eelouAuthor Commented:
Interesting stuff.  I do not have access to work from home.  I will try this tomorrow.
0
 
Vadim RappCommented:
> 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.
0
 
eelouAuthor Commented:
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
0
 
CSI-Windows_comCommented:
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.
0
 
eelouAuthor Commented:
I do not have those logs anymore.  This is the VB code...

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "msiexec /x {8B8FFF9E-AD55-4324-8E42-69DD90C55597} /qn"

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
0
 
CSI-Windows_comCommented:
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.
0
 
Vadim RappCommented:
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?
0
 
Vadim RappCommented:
> it must be that the VBscript shell is not under the control of InstallShield, and that must be why it works (???).

The way it works is, the execution phase is being performed by Windows Installer service.  In the log you can see "switching to server side". Because the service is only one, it can run only one installation at the time ( quite simplified), so that error message, "another installation in progress", is issued by the service. The service has no idea whether he was launched by vbscript, or by c++ initially - in fact c++ or vbscript launch msiexec running in user's session, and then msiexec in turn passes control to the service when the time comes.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now