Is there any way for an MSI package to control the return code from MsiInstallProduct? I've got a chainer that installs several MSI packages in sequence, and I'm looking for a simple way for packages to communicate a more nuanced status than simply success/failure/reboot.
What other types of results are you looking for? There's no reason custom actions can't store status or extended info about what happened in the registry. Success/failure/reboot is a consequence of the transactional nature of the install - it either works or not. You have a say in what makes it work or fail by using custom action return codes and so on. -- Phil Wilson The Definitive Guide to Windows Installer http://www.apress.com/book/view/1590592972
"John McNamee" <JohnMcNa...@discussions.microsoft.com> wrote in message
> Is there any way for an MSI package to control the return code from > MsiInstallProduct? I've got a chainer that installs several MSI packages > in > sequence, and I'm looking for a simple way for packages to communicate a > more > nuanced status than simply success/failure/reboot.
I was looking for a "failed, but that's OK" kind of status.
The situation is that I've got some packages that are only intended for certain OS versions. If I use the Condition table, the result is a general error exit code. I need my chainer to identify these situations, and handle them as a NOP rather than an error. Using the registry or some other back channel for communicating this status is certainly possible, but I was hoping for a cleaner solution. I may just move the platform detection logic into the chainer.
"Wilson, Phil" wrote: > What other types of results are you looking for? There's no reason custom > actions can't store status or extended info about what happened in the > registry. Success/failure/reboot is a consequence of the transactional > nature of the install - it either works or not. You have a say in what makes > it work or fail by using custom action return codes and so on. > -- > Phil Wilson > The Definitive Guide to Windows Installer > http://www.apress.com/book/view/1590592972
> "John McNamee" <JohnMcNa...@discussions.microsoft.com> wrote in message > news:98D0F3CA-C152-444B-9BE4-11E345EA9205@microsoft.com... > > Is there any way for an MSI package to control the return code from > > MsiInstallProduct? I've got a chainer that installs several MSI packages > > in sequence, and I'm looking for a simple way for packages to communicate >> a more nuanced status than simply success/failure/reboot.
That's what I did with a chainer too, otherwise it becomes very unmanagable with a whole bunch of MSI files with their launch conditions. It depends what the chainer's purpose is. When collecting several MSIs to chain together as a multi-MSI install that is a marketing product then there is one UI that wraps them all and they all need to install in some way. That's also the assumption behind the multi-MSI transactional things in MSI 4.x where they all install or not. -- Phil Wilson The Definitive Guide to Windows Installer http://www.apress.com/book/view/1590592972
"John McNamee" <JohnMcNa...@discussions.microsoft.com> wrote in message
>I was looking for a "failed, but that's OK" kind of status.
> The situation is that I've got some packages that are only intended for > certain OS versions. If I use the Condition table, the result is a > general > error exit code. I need my chainer to identify these situations, and > handle > them as a NOP rather than an error. Using the registry or some other back > channel for communicating this status is certainly possible, but I was > hoping > for a cleaner solution. I may just move the platform detection logic into > the chainer.
> --John
> "Wilson, Phil" wrote:
>> What other types of results are you looking for? There's no reason custom >> actions can't store status or extended info about what happened in the >> registry. Success/failure/reboot is a consequence of the transactional >> nature of the install - it either works or not. You have a say in what >> makes >> it work or fail by using custom action return codes and so on. >> -- >> Phil Wilson >> The Definitive Guide to Windows Installer >> http://www.apress.com/book/view/1590592972
>> "John McNamee" <JohnMcNa...@discussions.microsoft.com> wrote in message >> news:98D0F3CA-C152-444B-9BE4-11E345EA9205@microsoft.com... >> > Is there any way for an MSI package to control the return code from >> > MsiInstallProduct? I've got a chainer that installs several MSI >> > packages >> > in sequence, and I'm looking for a simple way for packages to >> > communicate >>> a more nuanced status than simply success/failure/reboot.