Scheduling a deferred CA from an immediate CA

A pattern which is apparently in wide use in Wix/DTF land is to author the .wxs file to execute only immediate-mode custom actions, and to have these custom actions schedule deferred custom actions. The reasons? The logic for sequencing custom actions in MSI can be quite byzantine because deferred custom actions cannot access msi session state. They can only access state via CustomActionData, and this state must be constructed by a previously-executed immediate custom action. Also, it's just plain easier to code the state-setup and condition logic as .NET code than it is to create a chain of tags and have to maintain their sequencing in the .wxs file.

To implement this pattern, simply author an immediate-mode DTF custom action whose implementation does something like this:


[CustomAction]
public static ActionResult SetupAction( Session session )
{
// Prepare custom action data for the deferred custom action
CustomActionData data = new CustomActionData();
data["SomePropName"] = session["SomePropName"];
// ...etc..
// Schedule the deferred action
session.DoAction("DeferredAction", data);
return ActionResult.Success;
}

[CustomAction]
public static ActionResult DeferredAction( Session session )
{
// Do whatever the real work is that changes the system state.
}


In general, you'll have an immediate-mode custom action for install, rollback, and uninstall, with one or more corresponding deferred actions.

Comments

Popular posts from this blog

Web Deployment Projects targeting x64

Unintuitive error in msi log when DTF is misconfigured

NServiceBus distributor configuration