Software Deployment

may seem like a rather obvious question, but did you create these MSIs yourself? Are they vendor MSIs?

You now know why nested MSIs are no longer recommended. Either deploy the MSIs separately or build a wrapper EXE to install them separately.

Hi,
yes, the MSI are created by myself and not really big.

Well, its not really a nested MSI, I just want to repair both when one will be repaired, means I only want to launch the msiexexc /foums command

so why have 2 MSIs?

becasue the customer want to have it that way

ORIGINAL: macduff
becasue the customer want to have it that wayIn that case, you - as the packaging 'expert' - need to explain that the two requirements (1, to have nested MSIs and 2, to have them both repaired with one command) are essentially mutually exclusive.

I suppose you *could* hack something together by adding a Custom Action to one of them which runs at repair time which will shell out and repair the other, but...really...it would be a monumental mess. And future maintenance? [shudder]

packaging 'expert' - need to explain that the two requirements (1, to have nested MSIs and 2, to have them both repaired with one command) are essentially mutually exclusive. I suppose you *could* hack something together by adding a Custom Action to one of them which runs at repair time which will shell out and repair the other, but...really...it would be a monumental mess. And future maint


Well, ok. its not 100% neccessary but it would be nice when it work with two seperated MSI which one can run the repair of the other

Mac,

First up i must concur that the guys above are on the right track, this isn't what you want as a solid production solution.

Second, i've been in your position! and i solved it by using a VBS script ( posting example. ) that monitors the MSIEXEC.EXE process and shoots the 2nd commandline when the MSIEXEC.EXE stops working or closes.

This way i managed to chain 3 MSI's so i could "overwrite" the nesting issue.


PROCESSCHECK.VBS
========================================================================
strComputer = "."
strProcName = "notepad.exe"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colMonitorProcess = objWMIService.ExecNotificationQuery _
("SELECT * FROM __InstanceCreationEvent WITHIN 1" & _
"WHERE TargetInstance ISA 'Win32_Process' AND TargetInstance.Name='" & _
strProcName & "'")
WScript.Echo "Waiting for " & strProcName & " process to finish..."
Set objLatestEvent = colMonitorProcess.NextEvent


Remember, this is only an example with notepad.exe you'll need to alter this to make your own.
( Due to company rights i cannot post the exact script. )

Regards,

NOxxie

Hi macduff,
i hope, i interpret your description correct.
Your client will have their reasons, to believe they need 2 packages for this.
Please, please find out what makes them believe this scenario is the best.
Are there other permissions? Are there situations, were only part of the stuff is needed?
What are those config files for? Do they have to be user editable?
Maybe this could be achieved by using Active Setup to reinstall a feature to each users profile?

However, one possibility would be to start the second MSI at the very end of the first.
That means, you create a custom action of type 226 to run the second MSI (226=128+64+34).
Something like this:
InstallYour2App 226 dirpropertyhere msiexec /i "[SecondApp.msi]" /f[REINSTALLMODE] /qb

And then call it from the very last position in InstallExecuteSequence:
InstallYour2App NOT Installed 7000

Another possibility would be to place the call into the InstallUISequence.
This would have the advantage, that it would happen only in interactive mode.
Then admins could still install it with deployment systems as separate packages, without changes.
Regards, Nick