Some basic functions of scripting languages are not available within a Windows Installer database file. One of the most common examples is the ability to write to a text file. The closes that an MSI can do is write to an ini file but there are many scenarios where the text you need to write doesn’t fall within a standard INI file notation.
MSI files give the ability to the Author of creating a Custom Action. A Custom action can be to call an executable, DLL procedure, VBScript or Jscript. The industry has pretty much settled on VBScript for use within Custom Actions
Unless you place a condition on the actions, they run every time the MSI is run (including repairs). This will cause problems if you are trying to remove the application and VBScript is trying to work on files that have been removed. For this reason, conditionals are placed on the Actions themselves.
The Custom Action below is conditional on the MSI already being installed and won’t run when the MSI is going through a “REMOVE” process. Most Custom Actions will have a conditional attached of “NOT REMOVE”.
All active Custom Actions must be inserted into the sequence table of the MSI so they are run at a particular time.
For corporate packaging, Custom Actions always go into the “Normal Execute Immediate / Deferred” Sequence. This corresponds to the “InstallExecute” table of the MSI. This guarantees that the Action will be run durin a normal install. Most corporate organisations have remote installation systems so “User Interface” sequences are never going to run anyway & no one seems to use Advertising (a shortcut is deployed and an Application is then installed if the shortcut is activated).
Note: A Custom Action must be placed before “InstallFinalize”
All Custom Actions have processing options that should be set.
We nearly always set the “Processing” option to “Synchronous, Ignore exit code” so that an error code given by a command line utility or by a VBScript doesn’t cause a fatal error that prevents the MSI from being installed.
The Inscript Option states when you want the Custom Action to run. An MSI installs in two phases. During Immediate execution, Windows Installer resolves the properties and references within the MSI database to absolute references for the machine in question. It prepares the installer script that will be run. When files and Registry keys are actually written to the machine, the MSI is in deferred mode – all of the original Properties of the MSI are unavailable. If you need to write to a file that will be installed, it has to be during this deferred mode. Custom Actions that change machine specific things should be set to run in “Deferred Execution – System Context”
Setting Permissions with Custom Actions
The current de facto method for setting permissions within the Application Packaging industry currently appears to be through using one of two executables embedded as a binary within an MSI and calling the utility as a Custom Action.
The “Type” column of the Custom Action table tells Windows Installer what type of Custom Action is being executed. Executable within the binary tables, scripts in the property table or different types of executables installed with other files within the product all carry their own Type code.
When permissions are being applied, remember that permissions must be applied in deferred mode. All folders have to have been created before permissions can be assigned, files must be installed before they have permissions applied as well.
SubiNACL is a Microsoft utility with relatively straight forward syntax. In the example above, SubiNACL is embedded within the binary table as a resource with the name “SubiNACL”.
The other utility is called SetACL http://helgeklein.com/setacl/ and has been developed to include an extended feature set to include more than just permissions of Files and registry keys.
- Log in to post comments