Deferred action and CustomActionData

[nitsev]

To have MSI property values (such as INSTALLDIR) available in a deferred action I understand that I must do the following.

1. Create a Set Property CA with a property name that is the same as the CA that is going to use the property (let's say MyCA for example)

2. Create a deferred CA that reads the property value using GetMSIProperty and pass CustomActionData to it.

Is there no easier way to pass MSI parameters to a deferred action? Let's say I have 10 deferred CAs that all need to get the INSTALLDIR property. In this case I must have 10 Set Property CAs (each with the property name of the deferred CA) that all set the exact same property value. It would of course be easier if they could all use the same value from ONE Set Property CA.
This seem very awkward if you ask me and is very error prone since changing the name of a Deferred CA will cause the CustomAction data to be unavailable cause the name of the deferred CA and the property value of the set property CA would differ.

[hidenori]

You can use an InstallScript custom action to set those properties by calling the MsiSetProperty() function for each property.

[nitsev]

hidenori wrote:
You can use an InstallScript custom action to set those properties by calling the MsiSetProperty() function for each property.

Thanks for the tip but from my experience I would like to keep as far away from InstallScript as humanly possible. It has caused me nothing but grief.

[Christopher_Pai]

When was the last time you used InstallScript? ( What version of InstallShield ) Several years ago InstallScript had an overhaul and it's not some big ugly scary beast as you might imagine.

10 deferred CA's must have 10 different CAD properties because:

1) This is how Microsoft designed it
2) To prevent information exposure

Now you didn't mention what custom action type your deferred CA's are. Are they C++? EXE? Script? C#/VBScript?

If C++... then create a single immeadiate CA in C++ that sets the 10 properties.

If VBScript, well I pity you for attacking InstallScript while you go down an even worse road.

If EXE, well they can't access the handle ... you just pass [INSTALLDIR] in as an argument, it'll get evaluated during the script generation phase and passed through during the script execution phase.

If you are using managed code, then check out WiX's DTF that has a CustomActionData class that makes it easy to serialize and deserialize complex datasets.

If you are ready to reconsider InstallScript, then you can check out my sample on InstallSite.

And if all else fails, you could just create 10 Type 51 CA's that all set INSTALLDIR to the CAD property of each of your deferred CA's.

[nitsev]

Hi Chris,

Thanks for your reply. My CAs are in a DLL written in Codegear Delphi. I am not sure what you mean by "If C++... then create a single immeadiate CA in C++ that sets the 10 properties." Could you please elaborate.

I must admit that it was several years since I used InstallScript. I abandonden it cause it was the single biggest cause for unsuccessful installations (the script engine could not be installed on the target machine etc.) I have skipped VBScript for the same reason. Even if InstallScript could be a valid option nowadays I'd prefer not to use it for 2 reasons.

1. All my other CAs are in the DLL so I'd like to keep everything in one place.
2. If I ever decided to use another tool I can still use my DLL, but all my installscript CAs would be useless.
3. Since it's written in Delphi, there's no limitations as to what can be done.

[Christopher_Pai]

1. All my other CAs are in the DLL so I'd like to keep everything in one place.
2. If I ever decided to use another tool I can still use my DLL, but all my installscript CAs would be useless.
3. Since it's written in Delphi, there's no limitations as to what can be done.

I tend to write data driven custom actions following single responsiblity principles and code reuse across many installers. It's better for me to have custom actions in multiple DLL's in order to prevent information exposure and package bloat.

InstallScript CA's are packaged as DLL's these days. They don't require preinstallation of a scripting engine and can be transplanted from MSI to MSI; even MSI's not authored in InstallScript.

Personally if you have a dependency on the .NET 2.0 framework or greater, I like DTF CA's written in C#... those can do Win API, COM and Managed APIs.

Eitherway, since you are already writing CA's in Delphi, just create a single CA that sets multiple properties. The names of the properties are the names of the Deferred CA's that they drive. This will allow you to make INSTALLDIR available to 10 CA's via CAD by using only 1 CA.

[manomatt]

I am having a managed dll and i need to pass some arguments to it while calling it..the arguments happen to be some poperties and i am calling the managed code custom action in deferred execution.i am a bit confused about how to pass a customActionData as paramers for a managed dll

some one please look into this and show some light into this. :confused:
thank you in advance


Mano

[manomatt]

The sample document http://community.installshield.com/attachment.php?attachmentid=7220&d=1217951981 talks about this

this will help you