Software Deployment

I'm guessing you're installing the MSI:s in UISequence which will not be used in Basic UI.

Problem with nested installation:
must be located in deferred execution (thats non-system context)
action in deferred execution is not executed during rollback

I would install these separate if you can.

I tried by making it in defered execution, but still not working, i even tried by extracting the msi seperatly and while installing it throws the error of data1.cab is not found.

If all msi files requires the data1.cab, extract it and change the media table to point to an external cab then all msi should be able to find the cab file.

can you tell me how to extract the cab files from msi.

You could use MSIExtractor (MsiX)
http://blogs.msdn.com/heaths/archive/2006/04/07/571138.aspx

As I discovered a couple of weeks ago, you can't run nested MSI's silently. They will only work when the UI is run.

When the UI is running, it's using MSIEXEC.EXE directly so it can call the windows installer service and both can run at the same time (that's why you see two instances of MSIEXEC.EXE when you run an install from the UI). But when you're installing silently, it only uses the service and the service can only work on one install at a time.

Hi folks,
don't mix up 'real' nested installations (CA 7/23) and calls to msiexec via CA 34.
The first one works with UI and silent installs, as the real installation is done inside MSI-script of the main app.
You can have rollback with it, but you have to author it yourself.
The second one does only work at certain points of the main apps installation.
It works in the UI sequence and after the 'InstallFinalize' action in the 'InstallExecuteSequence' with CA 34 (+192 = asynch/no return).
An example of the second one are the actual setups from Adobe (eg. Photoshop). They have built a CA exe-app that calls the helper MSI's (like bridge or help center) and installs them after the main app.
Hope this helps a bit.
Regards, Nick

To clarify what nheim said, a custom action type 34 only calls an executable. You can use this type of custom action to call "msiexec.exe /i blah.msi" but you'll run into the same problem as a nested install.

The only difference is that you can create rollback actions... so it's better, but still useless.

The only easy way you can chain these installs is if you create a setup.exe containing your MSI's, or use your distribution tool to chain them in succession.

You could conceivably create some sort of executable like his Adobe example, but that wouldn't be easy or best practice.

Hi turbokitty,
i only partly agree with you.
Rollbacks are not the only difference for the two methods. You can have a lot more control over the sub app with nesting (if you use it!) than with a call to msiexec.
Nesting isn't completely useless! There are reasons why the authors of the Installer built this feature. There are situations, where you have to use them. Key is to be aware of the weaknesses of the method you use.
Setup.exe is maybe good for a single installation, but not in a managed environment.

IMHO, avoid nesting, whenever it's possible, but use it in awareness of the flaws, when you have to.

Regards, Nick

Turbokitty... FYI - it is very possible to run a nested MSI at any UILEVEL...

First step - embed desired MSI into sub-storage ... use MSIDB.exe from the INstaller SDK

Next create CA that runs a Nested MSI - and have the executable be just the MSI name... Adobe.msi ... no parameters . Condition - Not Installed
also create a CA idenitical to this except in the parameters add REMOVE=ALL Condition - Installed

As you see one will run on installation and one on removal

next add them to you ExecuteSequence


--- Nested MSI's use the same parameters as passed to the main MSI ... so calling the main msi with a /qn or /qb will have the Nested MSI run the same way, this is not a valid parameter to pass.

I could not get this to work with installshield ... I don't know why but I could only get it to work using MSIDB.exe (make sure you use the option to "stream" in another database), and Orca(or other MSI table editor)

Enjoy

Hmm.. It's an interesting idea. When you say "I could not get this to work with Installshield", do you mean the whole thing won't work in Installshield, or part of it, or what?