Wix Toolset: How to determine installation mode in a Custom Action

Question

Is there any chance to check the type of the installation mode in a Custom Action. I want to create one Custom Action for both Install and Uninstall modes, but perform different logic based on the mode.

Something like:

public static ActionResult CreateBackUpAction(Session session)
{
    //if (InstallType == "Install")
    //{
    //  BackUpFiles();
    //}
    //else if (InstallType == "Remove")
    //{
    //    DeleteBackUpFiles();
    //}

    return ActionResult.Success;
}

I know that ideally I should have 2 different action for both cases, but I would like to minimize amount of lines in the installer's sources.

Answer 1

You should be able to use the session object's Item to get the property values of the current install. The value of session["REMOVE"] (it should be "ALL") will tell you it's an uninstall, and the value of session["Installed"] if it's a fresh install.

However, yes, you should use these types of conditions to call separate custom actions for a few reasons:

1. It means that you don't need to worry about deferred custom actions and properties and need to use the deferred custom action model with CustomActionData because Windows will take care of it. Using session ["REMOVE"], for example, may not work if the custom action is deferred. This documentation doesn't say that the Installed or REMOVE properties are available in deferred custom actions, so you'll be using session.CustomActionData with another custom action to set it.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa370543(v=vs.85).aspx

2. A managed code custom action call to an out of process method isn't cheap. You'll be calling into all that mechanism and returning, when you could just use Not Installed as a condition. If you have features that can be altered, or a repair happens then you will be calling again and returning again (having done nothing) if you have no conditions on the calls.

3. You don't have a good way to deal with rollback, because (for example) if the uninstall fails and rolls back I assume you would actually prefer to keep those backed-up files that you are deleting with your code. In other words, it's not clear what you want to do with those backed-up files in the event of an install failure, uninstall failure, rollbacks, and when you are upgrading an existing installed product.

It's also my opinion that several smaller focused custom actions that do one thing are easier to deal with than one large piece of code that is full of conditions.