cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cbarlow
Level 7

Running CA after a chained .msi

If I want to launch a custom action after running a chained .msi, does anyone know what Install UI sequence I should have it follow?
Labels (1)
0 Kudos
(7) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I've not tried from the UI sequence, but I suspect anything after ExecuteAction stands a chance. In general I would recommend a (deferred) Commit execution action in the InstallExecute sequence, but it does depend what you're trying to do.
0 Kudos
cbarlow
Level 7

My chained .msi installs a program. The custom action would access an installscript function and change the filename of the chained program executable. Since this approach depends on files that are installed by the chained msi, is a deferred action still recommended? Any ideas on what sequence the custom action belongs in and which action it should follow? I still can't get this to work.

Thanks!
0 Kudos
Christopher_Pai
Level 16

Can you just transform the MSI and get rid of the custom action?
0 Kudos
cbarlow
Level 7

Not sure what you mean by transform. The chained msi is a third party installer so I don't have access to the installation project for it. If I did, I would change the filename before building the install and then I wouldn't have to fuss with custom actions. Is this what you were getting at?

Thanks.
0 Kudos
rasky74
Level 6

You can use Orca or something to edit the msi directly to change the file name or create a Transform file to achieve this.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

The usual sequence order was like follows; note the outer UI items are completely skipped during silent e.g. /qn installs:

  • UI through ExecuteAction

    • Execute Immediates through InstallFinalize
    • Execute Deferred until error
    • If error, Execute Rollback from error back to start, no more execute
    • Otherwise Execute Commit
    • Execute Immediates after InstallFinalize

  • If no error, UI after ExecuteAction
  • Appropriate final action (e.g. sequence -1, generally a dialog) indicating error or success
In chained installs things get a little weird around Execute's Rollback/Commit/Immediate. I think it goes like this:

  • UI through ExecuteAction

    • Execute Immediates through InstallFinalize
    • Execute Deferred until error
    • If error, Execute Rollback from error back to start, no more execute
    • Execute Immediates after InstallFinalize
    • For each chained install:

      • Execute Immediates through InstallFinalize
      • Execute Deferreds
      • Execute Immediates after InstallFinalize

    • For each install, including chained:

      • If error, Execute Rollbacks in reverse order
      • Otherwise Execute Commit


  • If no error, UI after ExecuteAction
  • Appropriate final action (e.g. sequence -1, generally a dialog) indicating error or success
The items to note here are: UI after ExecuteAction comes last (just before the final dialog). Execute sequence immediates complete before Commit/Rollback actions are processed (this breaks standard usage of Support Files). The last Execute items processed are the Commit actions.

Unfortunately I'm not certain what the order of commit actions is between the various products, or if it's even specified. So if the chained install needs the old filename in a commit action (or in repair or uninstall, don't forget those), the custom action method is off. Christopher's suggestion of applying a transform is better, so long as the third party package has no untransformable references to the file (e.g. hardcoded in a custom action).
0 Kudos
cbarlow
Level 7

Thanks to both of you. You were very helpful, and I finally got it working.
0 Kudos