This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction. Use a condition of ‘NOT Installed’.The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed. Schedule this CA as ‘Deferred in a System Context’ and put it anywhere between the standard actions ‘InstallInitialize’ and ‘InstallFinalize’. In your script, to retrieve the directory name use:ĭim ProductName : ProductName = Session.Property("CustomActionData") It is IMPORTANT you call this the same name as your property you made earlier, so call it ‘AlkaneCustomProperty’. Execute this action as Immediate, before InstallInitialize with a condition of ‘NOT Installed’.Ĭreate another CA – this time a ‘Call VBScript from Embedded code’ (Type 38). Call it ‘AlkaneCustomProperty’ and give it a default value of anything (we’re going to set this to our directory name in Step 2….).Ĭreate a SetProperty custom action (Type 51), call it ‘setAlkaneCustomProperty’, select your ‘AlkaneCustomProperty’ property, and under property value write ‘’. In this example, we’ll pass the ProductName property during the installation of our product.Ĭreate a property. To pass any Windows Installer property to a deferred Custom Action, we must pass it via the CustomActionData property.
In brief (since this has been discussed plenty of times before elsewhere) this is due to them being executed in a separate process (they spawn another MSIEXEC.exe process which is run in a System Account context – check Task Manager during an installation to see this).
Deferred, commit, and rollback custom actions can only access a limited number of built-in Windows Installer properties – CustomActionData, ProductCode, and UserSID. This post describes how to access a Windows Installer property in a Deferred Custom Action.
0 kommentar(er)
