Custom Action that Terminates Specific Processes - Installshield 2012 Spring

InstallShield 2012 Spring includes support for a new kill-process type of custom action. If you add this type of custom action to your project, you can specify the name or process identifier (PID) of one or more processes that you want to be terminated at run time, and you can schedule the custom action for immediate or deferred mode.


The procedure for creating this type of custom action involves adding and configuring the custom action in the Custom Actions and Sequences view of your project, and using the Property Manager view to define a property with the names or PIDs of the appropriate processes.

Support for PowerShell Custom Actions - InstallShield 2012 Spring

Windows PowerShell is a .NET Framework–based command-line shell and script language that enables system administrators to automate system configuration tasks. InstallShield now has support for custom actions that run PowerShell scripts. You may want to add this type of custom action to a project to perform system configuration tasks at installation run time.


In order for an installation to run a PowerShell custom action, Windows PowerShell must be installed on target systems. InstallShield includes a new predefined PowerShell system search that checks for the presence of PowerShell on target systems. You can include this system search in your project and configure your PowerShell custom action to run only if the system search determines that PowerShell is installed.


The PowerShell execution policy, which determines whether PowerShell scripts can be run on a target system, is set to restricted by default, which does not permit PowerShell scripts to be run. If you want your installation to override the target system’s execution policy with an appropriate one for your installation’s PowerShell custom actions, you can use the new Windows Installer property IS_PS_EXECUTIONPOLICY to indicate the appropriate execution policy.

Software Identification Tag - Installshield

ISO/IEC 19770-2 is an international standard for the creation of software identification tags. A software identification tag is a small XML-based file that contains descriptive information about the software, such as the product name, product edition, product version, and publisher. Software asset management tools collect the data in the tags to provide accurate application identification for software that is installed in an enterprise.


Software identification tagging is evolving as an industry standard, enabling independent software vendors to create smarter applications that give their customers better information for software asset management and license optimization initiatives. Including the identification tag in your product’s
installation makes it possible for your customers to use tools that can monitor their internal usage of your product, allowing them to understand, manage, and optimize the number of licenses of your product that they obtain from you.


Proper tag creation requires that you configure standard General Information settings such as Product Name and Product Version. It also requires that you configure a few identification-specific settings, which are also in the General Information view.

Windows File Versioning Rules

Suppose your installation source contains a file named newstuff.dll, and the
Installer finds a copy of newstuff.dll already on the user’s hard drive. How
would you decide whether to overwrite the existing copy on the hard drive with a new copy from the source media? Your first idea might be to compare file dates; you would then overwrite if the copy in the source media was newer. A more sophisticated version of this technique is to look at the internal file version information, and overwrite if the copy in the source media has a higher version.


The Windows Installer uses an even more complex algorithm when deciding
whether to keep an existing file or install a new copy. It takes into account not just the file dates and the version, but the languages involved as well. Here’s the set of rules the Windows Installer follows:

Highest version wins: All other things being equal, the file with the highest
version number wins, whether that’s the file on the hard drive or the file in the
source media.


Any version is higher than no version at all: If the copy in the source media
contains version information, and the copy on the hard drive has no version
information, Windows Installer chooses the one with the version information.


Favor the new language: All other things being equal, if the file being
installed is localized for a different language than the file on the computer, Windows Installer uses the copy with the language that matches the product being installed.


Meet the product’s needs for multiple languages: If both copies support
multiple languages, Windows Installer ignores the common languages and uses the copy that supports the most languages out of the set of languages that the product uses.


Keep the maximum number of languages: If the copies differ in the number
of languages they support and both support all the languages that the product
needs, Windows Installer keeps the copy that supports the most languages.


Treat non-versioned files as user data: If there is no version information for
either copy, Windows Installer compares the file creation date and the last modification date for the file on the computer. If the modification date is later than the creation date, Windows Installer assumes this file has been customized by the user and does not overwrite it. Otherwise, it installs a new copy.


Companion files go along with the versioned file: It’s possible to mark a
file within the Installer database that does not include version information as a companion file to a file that does include version information. In this case, the companion file is installed if the other file is installed. There is one exception to this rule, though. If the companion file is not present on the target machine, it’s installed even if the versioned file is not installed.


It’s a good thing that these rules match the way most developers would like
installations to behave because there’s no way for you to change them. Of course, you can pervert their intention if you feel you must. One way to guarantee that a file from the source media is installed is to set its version string in the File table to 65535.65535.65535.65535, which is the maximum version number that the Windows Installer accommodates. Beware, though: if you do this, you’ll never be able to use the Windows Installer to replace that copy of the file with a new version.

MSI Just-in-time (JIT) installation

Just-in-time (JIT) installation—A package need not be fully installed right away. If a feature or component of the package is needed later, it can be grabbed from the source and loaded JIT—all while the application is already started.

MSI Custom Action Type Flags

Value added to Type	Effect
0	Synchronous execution. Fails if exit code is not zero., Always executed. Immediate execution.
+64	Synchronous execution. Exit code is ignored
+128	Asynchronous execution. Fails if exit code is not zero.
+192	Asynchronous execution. Exit code is ignored
+256	Execute once. If the action is in both the UI and Execute sequence tables, it is executed only in the UI sequence table if the user interface is used, and it is executed only in the Execute sequence table if the user interface is not used.
+512	Execute once per process. If the action is in both the UI and Execute sequence tables, and both tables are read by the same process, it is executed only in the UI sequence table if the user interface is used, and only in the Execute sequence table if the user interface is not used
+768	Execute only on client after UI sequence. This custom action is in the Execute sequence table, but it should not be run if the user interface is suppressed.
+1024	Deferred execution custom action
+1280	Rollback custom action
+1536	Commit custom action
+3072	Deferred custom action run in the system process.

MSI Custom Action Types

This table also shows how you should interpret the Source and Target columns for each type of custom action

Type	Description	Source	Target
1	.dll stored in a binary Stream	Key to a row in the Binary table	Name of the .dll entry point.
2	.exe stored in a binary Stream	Key to a row in the Binary table	Command-line string used to launch the .exe.
5	JScript in a binary Stream	Key to a row in the Binary table	Name of the JScript function to call.
6	VBScript in a binary Stream	Key to a row in the Binary table	Name of the VBScript function to call
7	Installation of a package nested inside of the first package	Name of the substorage containing database of nested application.	Properties settings string.
17	.dll installed as part of a product	Key to a row in the File Table	Name of the .dll entry point.
18	.exe installed as part of a product	Key to a row in the File Table	Command-line string used to launch the .exe.
19	Displays a specified error message and returns failure, terminating the installation	Blank	Formatted text string. The literal message or an index into the Error table.
21	JScript file installed as part of a product	Key to a row in the File Table	Name of the JScript function to call.
22	VBScript file installed as part of a product	Key to a row in the File Table	Name of the VBScript function to call.
23	Installation of a package that resides in the first application’s source tree	Path of nested package specified relative to the root of the source location	Properties settings String
34	EXE in a known Directory	Key to a row in the Directory table	Name of the executable file and any options. Use quotes to surround long file names.
35	Directory set via formatted text	Key to the Directory Table	Formatted text string that will be set as the directory path when this action is executed.
37	JScript text	Null	A string of JScript code to execute.
38	VBScript text	Null	A string of VBScript code to execute.
39	Installation of an application that is advertised or already installed	Product Code for the application to install	Properties settings String
50	.exe named by a Property	Property name or key to a row in the Property table	Command-line string used to launch the .exe.
51	Property set via formatted text	Property name or key to the Property table	Formatted text string that will be stored in the property when this action is executed.
53	JScript text stored in a Property	Property name or key to a row in the Property table	Name of the JScript function to call.
54	VBScript text stored in a property	Property name or key to a row in the Property table	Name of the VBScript function to call.