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

Only One CustomActionData allowed?

Has anyone experienced this. I have TWO rollback actions in an installer. One works fine, but the other will not allow CustomActionData to be passed to it.

I have scrutinized the two again and again. Both are virtually parallel in the installer.

Each has its own Property set custom action to pass the needed property values to the rollback action.

The name of the property being set in bo:confused: th instances is the name of the rollback Custom Action.

Property set occurs in the InstallExecute sequence along with the Rollback actions (both engage during rollback). Property set is before rollbacks and rollbacks are after InstallInitialize.

Everything looks parallel, but the MsiGetProperty(ISMSI_HANDLE, "CustomActionData" . . .) in the second function returns NOTHING . . . Zip . . . NULL.

Is there some rule that you are allowed only one CustomActionData property per install session ? . . . that you have to put all your rollback actions into one custom action. That you have to use the same CustomActionData property for ALL rollback actions?

I am annoyed.
Labels (1)
0 Kudos
(2) Replies
TsungH
Level 12

You can have many deferred custom actions (rollback included), and each can have its own unique CustomActionData property. Without the verbose log, I will recommend checking for typos in property name, and making sure custom action that sets the property is an immediate custom action. If everything else fails, check the log.
0 Kudos
Peter_Kosenko
Level 7

You are right. I'm still not sure why I was initially getting null out of the CustomActionData property. Eventually, I started getting "1;;;" (four properties, three of which were empty). Some of the properties were not yet set at the time I was passing them to the rollback custom action property.

However, the "read the verbose log" recommendation is really of limited use. That log does not EXPLAIN anything. It just babbles on incomprehensibly.

In fact, what is needed is a good autopsy of MSI that explains EVERYTHING that happens (at the MSI code level), and in what order, when the installer runs. Even better, Microsoft should publish the MSI code rather than the paltry "technical documentation" that it releases.
0 Kudos