How to pass CustomActionData to a CustomAction using WiX?

Question

How are properties set on CustomActionData to be retrieved by a deferred custom action?

Zaragoza

Github-sample of a deferred mode C# custom action. From this answer. And the basic WiX constructs summarized here. – Heavyduty

Answer 1

Deferred custom actions can not directly access installer properties (reference). In fact, only CustomActionData property

session.CustomActionData

and other methods and properties listed here are available on the session object.

Therefore, for a deferred custom action to retrieve a property such as the INSTALLLOCATION, you have to use a type 51 custom action — i.e. a set-property custom action — to pass that information along and you'll consume the data from the CustomAction's C# code through session.CustomActionData. (see reference & reference)

Below is an example of a type 51 custom action (CustomAction1) that will set a property that can be retrieved in CustomAction2.

<CustomAction Id="CustomAction1"
              Property="CustomAction2"
              Value="SomeCustomActionDataKey=[INSTALLLOCATION]"
/>

Notice that Property attribute name is CustomAction2. This is important. The Property attribute's value of the type 51 action must be equal/identical to the name of the custom action that is consuming CustomActionData. (see reference)

Notice the name SomeCustomActionDataKey in the Value attribute key/value pair? In your C# code in the consuming custom action (CustomAction2), you'll look-up that property from CustomActionData by using the following expression:

string somedata = session.CustomActionData["SomeCustomActionDataKey"];

The key that you use to retrieve the value from CustomActionData is NOT the value in Property attribute of the type 51 custom action, but the key from the key=value pair in the Value attribute. (Important takeaway: CustomActionData is populated by setting an installer property that has the same name as the Id of the consuming custom action, but CustomActionData keys are NOT installer properties.) (see reference)

In our scenario the consuming custom action is a deferred custom action defined somewhat like the below:

<Binary Id="SomeIdForYourBinary" SourceFile="SomePathToYourDll" />
<CustomAction Id="CustomAction2"
              BinaryKey="SomeIdForYourBinary"
              DllEntry="YourCustomActionMethodName"
              Execute="deferred"
              Return="check"
              HideTarget="no"
/>

Configuring the InstallExecuteSequence

Of course, the consuming custom action (CustomAction2) must run after the type 51 custom action (CustomAction1). So you'll have to schedule them like this:

<InstallExecuteSequence>
  <!--Schedule the execution of the custom actions in the install sequence.-->
  <Custom Action="CustomAction1" Before="CustomAction2" />
  <Custom Action="CustomAction2" After="[SomeInstallerAction]" />      
</InstallExecuteSequence>

Zaragoza

Alexey, thanks for taking the time to write this up. This has been a really big help to me. Unfortunately I can only give you +1... – Pomerania

As @TimLong said, a huge thank you. Wish I could +1 this many, many times. – Near

Did not understand it until I actually ran it. Then I saw the logic. Way to little GOOD readable info on this topic. Thanks! – Daric

If you need to pass more then one parameter, you cannot add another CustomAction, they overwrite, but you should set your parameters separating them with a semicolon: Value="ActionDataKey1=Value1;ActionDataKey2=Value2". – Calandra

You don't have to follow the key-value-pair format, you can provide any string value and read it with session.CustomActionData.ToString(). – Hophead

I stumbled across this question whilst looking for a solution to write settings to appsettings.Json file after a ASP.NET MVC Core installation. I wrote a CustomAction to do it, but it was stumbling over when it tried to write to settings file during installation because of permission issues. The only way to do it was to defer the execution but I had the problem of not being able to access the session object. I was trying to use CustomActionData but the sample code I grafted was setting it incorrectly. Your example is the correct way. Many Thanks! – Tawanda

I had hoped to use the CustomAction to set some global variable in my custom action DLL -- like a configuration value -- one that could be referenced by other CustomActions. But the configuration value does not persist across calls into the DLL; as though every call into the the DLL is bracketted with DLL_PROCESS_ATTACH/DLL_PROCESS_DETACH, so the config value is lost. – Northampton

I wish I could mark it +100 :-(. Thanks, it's a brilliant explanation – Gingerich

Answer 2

For us C++ schlubs, you retrieve the Property as follows:

MsiGetProperty(hInstall, "CustomActionData", buf, &buflen);

Then you parse 'buf'. Thank you to Bondbhai.

Anzac

Answer 3

If the value passed to the custom action is not a key/pair set...

i.e.

<SetProperty Id="CustomAction1" Before="CustomAction1" Value="data" Sequence="execute"/>
<CustomAction Id="CustomAction1" BinaryKey="BinaryId" DllEntry="MethodName" Execute="deferred"/>

...then the entire blob can be retrieved using:

string data = session["CustomActionData"];

Capability