Open topic with navigation
InstallShield includes the following new features.
Support for Windows 10–Based Systems
InstallShield has support for Windows 10.
Targeting Windows 10
On systems with Windows 10, the Windows Installer properties VersionNT and VersionNT64 indicate 603, which was originally introduced as the version number of Windows 8.1. Therefore, it is not possible to create conditions in an .msi package that specifically target Windows 10.
Since Windows Installer 5.0 and Windows 7, DLL custom actions in .msi packages are shimmed to block obtaining the operating system version; the APIs GetVersion, GetVersionEx, and RtlGetVersion return a Windows version of 6.0.6000, which was originally the version number of Windows Vista. Therefore, it is also not possible to obtain the actual version number of Windows from a DLL custom action or from an InstallScript custom action (which is implemented as a DLL).
Because of the aforementioned behavior in Windows Installer, it is not easily possible to detect what version of Windows on which an .msi package is running. In areas where you can specify target system OS requirements, such as the Installation Requirements page in the Project Assistant of Basic MSI and InstallScript MSI projects, the Windows 8.1 option has been renamed as Windows 8.1 or Windows 10 to reflect the new run-time behavior.
InstallScript, Advanced UI, and Suite/Advanced UI projects provide the ability to properly detect which version of Windows (including Windows 10) is present on a target system. Thus, if your installation needs to target or exclude Windows 10, you may want to use these types of projects to create conditions under which .msi packages should be run based on the actual target system platform.
The InstallShield prerequisites that should be installable on Windows 10 have been updated so that they are installed on those systems if needed. Previously, the prerequisites may not have run by default on those systems.
InstallScript Language Support for Windows 10
The following structure members and predefined constants were added to the InstallScript language:
|•||SYSINFO.WINNT.bWin10—This is a new SYSINFO structure member. If the operating system is Windows 10, this value is TRUE. (This is applicable to InstallScript event-driven code; it is not applicable to custom actions.)|
|•||ISOSL_WIN10—This is a new predefined constant that is available for use with the FeatureFilterOS function and the SYSINFO structure variable. It indicates that the target system is running Windows 10.|
For more information, see FeatureFilterOS function and the SYSINFO structure variable.
Support for Microsoft Visual Studio 2015
InstallShield includes support for Visual Studio 2015. You can create InstallShield projects from within this version of Visual Studio.
Digital Signing Improvements
InstallShield includes several improvements for digitally signing your installations and files at build time.
Support for SHA-256 Digital Certificates
InstallShield now enables you to use digital certificates that use the SHA-256 hashing algorithm for signing your installations and files at build time.
SHA-256 is favored over SHA-1, which is being deprecated because of the potential for security vulnerabilities. Microsoft announced that Windows will stop trusting items that were signed and timestamped with SHA-1 certificates after January 1, 2016. In addition, certification authorities—the organizations that issue certificates—are phasing out the creation of SHA-1 certificates. Thus, it is recommended that you replace any SHA-1 certificates in your InstallShield projects with SHA-256 certificates. For the latest information and more specific details, check with your certification authority.
In InstallShield, to replace a SHA-1 certificate with a SHA-256 certificate for signing your releases, use the Signing tab in the Releases view to replace the reference to the current certificate with one for a SHA-256 certificate.
If your project is configured to sign with a SHA-256 certificate, InstallShield uses a SHA-256 hash in the signature of the files that it signs at build time. If your project is still configured to sign with a SHA-1 certificate, InstallShield uses a SHA-1 hash; in addition, use of a SHA-1 certificate now triggers build warning -7346 to alert you about the SHA-1 usage.
In earlier versions of InstallShield, InstallShield used a SHA-1 hash in the signature of files when signing with either SHA-1 and SHA-256 certificates.
For details, see Digital Signing and Security.
Ability to Use a Certificate Store for Referencing Certificates
When you are specifying the digital signature information that you want to use for signing your files and installations, InstallShield now lets you reference a certificate store that contains the certificate that you want to use. This support is available as an alternative to specifying a .pfx certificate file on your machine.
To specify whether you want to use a certificate store or a .pfx certificate, use the Digital Certificate File setting on the Signing tab in the Releases view. When you click the ellipsis button (...) in this setting, a new Certificate Selection dialog box opens, enabling you to specify certificate information such as the store name (Personal, Trusted Root Certification Authorities, Enterprise Trust, Intermediate Certification Authorities), the store location (user or machine), and the subject that identifies the specific certificate that you want to use. As an alternative, you can specify on this dialog box the path and file name of a .pfx file that you want to use.
If you configure your project to use a certificate that was imported with password protection into a store, Windows prompts for the password at build time when InstallShield is attempting to sign your project’s files. The strong key protection that Windows uses does not permit InstallShield to provide the password to the cryptographic provider.
Certificate store support is also available for signing patches and QuickPatch packages:
|•||To specify certificate store or .pfx certificate information for a patch, use the Digital Signing tab for a patch configuration in the Patch Design view.|
|•||To specify certificate store or .pfx certificate information for a QuickPatch package, use the Build Settings area of the General Information view in the QuickPatch project. This area includes a Digital Signature tab that includes the new support.|
In addition, the command-line tool iSign.exe, which is available for signing already-built InstallScript releases, has been updated to include support for using certificates in certificate stores.
To learn more, see:
|•||Digital Signing and Security|
|•||Certificate Selection Dialog Box|
|•||Signing Tab for a Release (for a release in the Releases view)|
|•||Digital Signature Tab (for a patch configuration in the Patch Design view)|
|•||Digital Signature Tab (in a QuickPatch project)|
Note that InstallShield no longer has support for signing with .spc and .pvk files. To learn how to convert those files to a .pfx file, see Digital Signing and Security.
Ability to Specify a Program Name for the UAC Dialog Box
The Signing tab in the Releases view includes a new Signature Description setting. Use this setting to specify the text that you want to be displayed to the right of the “Program Name:” label on the UAC dialog box for the Setup.exe files, the .msi file, and other installation files that InstallShield signs at build time. The UAC dialog box opens when an end user launches the signed file and elevated privileges are required.
If you leave the Signature Description setting blank, InstallShield uses the name of the file without its extension as the text on the UAC dialog box.
For more information, see Signing Tab for a Release.
Ability to Digitally Sign Media Header Files with a .pfx File or a Certificate in a Certificate Store
InstallShield now has support for using .pfx files to sign media header files (.hdr files), which are used for the One-Click Install type of installation for InstallScript projects. As an alternative, you can use a certificate in a certificate store to sign media header files.
Previously, it was necessary to sign with .spc and .pvk files instead of .pfx files.
Automation Interface Support for Specifying Digital Certificate Information
The automation interface has support for specifying the .pfx file and the certificate store information. In addition, it also has support for specifying the signature description.
In Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, and Merge Module projects, the ISWiReleases object includes two new read-write string properties.
|•||DigitalCertificateInfo—This property gets or sets either the path to the .pfx file on your machine, or to a string that indicates certificate store details.|
|•||SignatureDescription—This property gets or sets the signature description.|
To learn more, see ISWiRelease Object.
In Advanced UI and Suite/Advanced UI projects, the ISWiSuiteReleases object includes these same new properties. For more details, see ISWiSuiteRelease Object (Advanced UI and Suite/Advanced UI).
Ability to View Both the 32- and 64-Bit Areas of the Source Machine’s Registry on 64-Bit Development Systems
If you are using InstallShield on a 64-bit development system, the Registry view in InstallShield now displays both the 32-bit and 64-bit areas of your machine’s registry:
This support makes it easier to develop installations on 64-bit machines, since it enables you to drag and drop entries from those source areas to the appropriate areas in the destination pane of this view.
Previously, if you were using InstallShield on a 64-bit development system, the source panes in the Registry view in InstallShield did not show any 64-bit data from the HKLM\Software part of the registry; in addition, the source panes displayed 32-data from the machine’s HKLM\Software\Wow6432Node area in the HKLM\Software area.
Note that if you want your installation to install registry data to a 64-bit area of the registry on 64-bit target systems without having it redirected to a 32-bit area, you must place the registry data in a component that is marked as 64 bit. Simply dragging 64-bit data from the source panes in the Registry view to a location in one of the destination panes of the view does not mark the component as 64 bit.
This feature is available in the following project types: Basic MSI, DIM, InstallScript, InstallScript MSI, InstallScript Object, Merge Module, MSI Database, MSM Database, and Transform.
For more information, see:
|•||Developing and Building Installations on 32-Bit vs. 64-Bit Systems|
|•||Dragging and Dropping Registry Entries to Create Registry Keys|
Support for Embedding Formatted Expressions in Advanced UI and Suite/Advanced UI Projects for Run-Time Resolution
In various areas of Advanced UI and Suite/Advanced UI projects, you can now embed object expressions to query target systems for information about a file, a registry entry, the operating system, or other details. This enables you to dynamically configure many of the Advanced UI or Suite/Advanced UI settings at run time based on target system–specific conditions. Object expressions use this convention:
[@Object(Parameters, ...).Property(Parameters, ...)]
Each object expression contains a reference to an object, which is a collection of object-specific properties. Objects and properties may contain parameters.
For example, the following Platform object expression obtains the architecture (x86, x64, IA64, ARM, or Unknown) of the machine on which the Advanced UI or Suite/Advanced UI installation is running:
The following Registry object expression obtains the value data of the RegisteredOwner value for the HKLM\Software\My Company Name\My Product Name registry key:
You can embed object expressions within other formatted expressions, such as within property expressions or other object expressions. In the following expression, a Registry object expression is embedded as part of the parameter to a File object expression.
If the MyProduct.exe file is in the location that is specified for the MyProductPath value data, the File object expression returns the version of the file. If the file is not found in that location, or if the registry value does not exist, the File object expression returns an empty string.
InstallShield also now enables you to pass literal square brackets as part of strings through the command line to packages in an Advanced UI or Suite/Advanced UI installation. For example, a command line such as [\Text[\]] resolves as [Text] at run time and is passed to the package with the square brackets. Previously, a string enclosed within square brackets was treated as a property that the installation attempted to resolve at run time. The only work around was to use a formatted property expression (such as [PropertyForSquareBracketString]) that would be resolved at run time to a property value that included the square brackets.
To learn more, see:
|•||Using Formatted Expressions that Advanced UI and Suite/Advanced UI Installations Resolve at Run Time|
|•||Writing Object Expressions in Advanced UI and Suite/Advanced UI Projects to Search Target Systems|
|•||Object Reference for Expressions in Advanced UI and Suite/Advanced UI Projects|
Ability to Share Common Packages Among Different Advanced UI and Suite/Advanced UI Installations
When you are configuring a package for an Advanced UI or Suite/Advanced UI installation, you can now mark it as shared. The shared package functionality helps to ensure that if two or more Advanced UI or Suite/Advanced UI installations are sharing a package, the package remains on the target system until all of the Advanced UI and Suite/Advanced UI products are removed.
To mark a package that is selected in the Packages view of an Advanced UI or Suite/Advanced UI project as shared, select Yes for the new Shared setting. In addition, ensure that the package GUID is the same across all Advanced UI and Suite/Advanced UI projects that are sharing the package; the Package GUID setting in the Packages view is where you can view and modify the GUID of a package.
Before this built-in shared support was available, unexpected results may have occurred in various scenarios. For example, in some scenarios, if two different Advanced UI or Suite/Advanced UI installations installed a shared package on a target system and then only one was uninstalled, the shared package was removed. The remaining Advanced UI or Suite/Advanced UI product may have been unusable because of the missing shared package. In other scenarios, the shared package was erroneously left behind on a target system, even though no Advanced UI or Suite/Advanced UI product remained.
This feature is available for the following types of packages in Advanced UI and Suite/Advanced UI projects: .msi, .msp, .exe, .appx, InstallScript, Basic MSI project, and InstallScript project.
For more details, see:
|•||Sharing Common Packages Among Different Advanced UI and Suite/Advanced UI Installations|
Ability to Override the Product Name, Product Version, and Suite GUID for a Release in an Advanced UI or Suite/Advanced UI Project
InstallShield now lets you override the product name, product version, and Suite GUID values that are specified in the General Information view of your Advanced UI or Suite/Advanced UI project with a new value for a selected release. To override the General Information view values, use the new settings that are available on the Build tab for a release in the Releases view: Product Name, Product Version, and Suite GUID.
For details, see Build Tab for a Release.
Ability to Override the Values of Path Variables for a Release in an Advanced UI or Suite/Advanced UI Project
InstallShield now lets you override the values of your project’s custom path variables (standard path variables, environment path variables, and registry path variables) for each release in your project. This functionality enables you to essentially replace certain files and folders in your project with others at build time, depending on the particular release that you are building.
For example, you might want to use this functionality to swap out UI elements such as images and EULAs for different releases in your project; this would enable you to easily generate installations for different editions or branded versions of your product.
To override one or more path variables in your project, use the Path Variables Overrides setting, which is on the Build tab for a release in the Releases view.
To learn more, see the following:
|•||Overriding the Value of a Custom Path Variable for a Release|
Automation Interface Support for Advanced UI and Suite/Advanced UI Projects
InstallShield now enables you to automate most development and build processes of Advanced UI and Suite/Advanced UI projects (.issuite files) through the automation interface without having to directly open the InstallShield interface and make changes in different views. The automation interface provides programmatic access to various areas of Advanced UI and Suite/Advanced UI projects; it exposes a COM interface that you can call from many languages to create, edit, and build Advanced UI or Suite/Advanced UI projects.
The top-level automation object for Advanced UI and Suite/Advanced UI projects is the ISWiProject object. Sample VBScript code that opens, modifies, saves, and closes a project begins and ends like this:
Dim pProj As ISWiProject
Set pProj = CreateObject("ISWiAutoSuite22.ISWiProject")
pProj.OpenProject "C:\InstallShield 2015 Projects\Project1.issuite"
' perform changes here
By calling methods, getting and setting properties, and accessing collections, you can also add features and packages to your project, configure conditions, and more. For more information, see the following sections of the documentation:
|•||Automation Objects for Advanced UI and Suite/Advanced UI Projects|
|•||Automation Collections for Advanced UI and Suite/Advanced UI Projects|
Note that the ProgID for the Advanced UI and Suite/Advanced UI automation interface is ISWiAutoSuite22.ISWiProject; the ProgID for other project types is simply ISWiAuto22.ISWiProject.
New InstallShield Prerequisites for Microsoft Visual C++ 2015, .NET Framework 4.6, and More
InstallShield includes new InstallShield prerequisites that you can add to your projects:
|•||Microsoft Visual C++ 2015 Redistributable Package (x64)|
|•||Microsoft Visual C++ 2015 Redistributable Package (x86)|
|•||Microsoft Visual C++ 2013 Redistributable Package (x86)|
|•||Microsoft Visual C++ 2013 Redistributable Package (x64)|
|•||Microsoft .NET Framework 4.6 Full|
|•||Microsoft .NET Framework 4.6 Web|
|•||Microsoft .NET Framework 4.5.2 Full|
|•||Microsoft .NET Framework 4.5.2 Web|
|•||Microsoft SQL Server 2012 Express SP2 (x86)|
|•||Microsoft SQL Server 2012 Express SP2 (x86 & x64Wow)|
|•||Microsoft SQL Server 2012 Express SP2 (x64)|
|•||Microsoft SQL Server 2012 Express SP2 LocalDB (x86)|
|•||Microsoft SQL Server 2012 Express SP2 LocalDB (x64)|
|•||Microsoft SQL Server 2012 Express SP2 Management Objects (x86)|
|•||Microsoft SQL Server 2012 Express SP2 Management Objects (x64)|
|•||Microsoft SQL Server 2012 Express SP2 System CLR Types (x86)|
|•||Microsoft SQL Server 2012 Express SP2 System CLR Types (x64)|
|•||Internet Explorer 11.0 for Windows 7 (x86)|
|•||Internet Explorer 11.0 for Windows 7 and Windows Server 2008 R2 (x64)|
|•||Microsoft ReportViewer 2012|
These prerequisites install the appropriate technologies on supported target systems.
The Microsoft SQL Server 2012 Express SP2 prerequisites replace the Microsoft SQL Server 2012 Express SP1 prerequisites.
New Predefined System Searches for Internet Explorer 10 and 11
InstallShield has new predefined system searches that check target systems for Internet Explorer 10 or Internet Explorer 11. If your installation or product requires either of those versions, you can use the System Search view or the Installation Requirements page in the Project Assistant to add one of these system searches to your project. When end users launch your installation, Windows Installer checks the target system to see if the requirements are met; if they are not met, the installation displays the error message that is defined for the system search.
This change is available in Basic MSI and InstallScript MSI projects.
Support for Creating Virtual Applications for Microsoft App-V 5.0 SP3; Additional App-V Package Improvements
InstallShield and the Microsoft App-V Assistant in InstallShield include support for creating virtual applications that can run on Microsoft App-V 5.0 SP3 clients. In addition, the Microsoft App-V Assistant includes new settings and capabilities—some of which apply to App-V 5.0 SP3, and some of which apply to earlier versions of App-V.
New InstallShield Prerequisites for App-V 5.0 SP3
InstallShield includes new InstallShield prerequisites that you can add to Advanced UI, Basic MSI, InstallScript, InstallScript MSI, and Suite/Advanced UI projects:
|•||Microsoft App-V 5.0 SP3 Desktop Client (x86)|
|•||Microsoft App-V 5.0 SP3 Desktop Client (x64)|
The redistributable files for these InstallShield prerequisites are not available for download from within InstallShield, since you must obtain them from Microsoft. Once you obtain one of the redistributables from Microsoft, place it in the location that is displayed when you are editing the prerequisite in the InstallShield Prerequisite Editor.
Ability to Map Files into the Virtual File System Instead of a Primary Application Directory
The Microsoft App-V Assistant now enables you to configure your App-V package to map files into the virtual file system (VFS). This support is available for App-V 4.x and 5.x packages.
To specify whether you want to map the files to the VFS or use a primary application directory, use the Files page in the Microsoft App-V Assistant. The More Options area on this page has a new File Mapping link. When you click this new link, a new File Mapping dialog box opens, enabling you to select the appropriate option.
The File Mapping link and dialog box replace the Primary Application Directory link and dialog box, which previously enabled you to specify primary application directory.
To learn more, see File Mapping Dialog Box.
Ability to Create App-V 5.x Packages that Have Full Write Permissions to the Virtual File System
The Microsoft App-V Assistant now enables you to specify whether you want an App-V 5.x package that you are creating to have full write permissions to the virtual file system (VFS). To specify whether you want to use this support, use the new Allow full write permission to the VFS check box. This check box is on the File Mapping dialog box, which is available from the Files page in the Microsoft App-V Assistant when you click the File Mapping link in the More Options area.
To learn more, see File Mapping Dialog Box.
Ability to Configure Advanced COM Isolation Settings for App-V 5.x
The Microsoft App-V Assistant now enables you to configure advanced settings for COM isolation. This support is available for App-V 5.x packages.
To configure the new settings, use the Package Information page in the Microsoft App-V Assistant. The More Options area on this page has a new Isolation Settings link. When you click this new link, a new Isolation Settings dialog box opens. This dialog box enables you to specify whether you want to isolate the COM objects from the local system, or allow them to interact with the local system. This dialog box also lets you indicate whether you want to isolate named objects from the local system, or allow them to interact with the local system.
To learn more, see Isolation Options Dialog Box (for a Package).
The Microsoft App-V Assistant is available in the Virtualization Pack.
Performance Improvement for the Files and Folders View
InstallShield has been enhanced to more quickly load the Files and Folders view of large projects.
Ability to Filter Items in the Files and Folders View by Feature
The Files and Folders view now contains a View Filter that lists each of the features in your project, as well as an All Application Data option. You can use this filter to show and hide files and folders in the destination panes of this view:
|•||To see in this view only files and folders that belong to a particular feature, select that feature in the View Filter list.|
|•||To add a file or folder to a specific feature, select that feature in the View Filter list. Then add the file or folder to the appropriate location in the Destination computer’s folders pane.|
|•||To see all of the files and folders that are in your project, select the All Application Data option in the View Filter list.|
The new View Filter replaces the previous Add new components to the feature filter, which did not have support for showing and hiding files and folders in the view according to the selected feature.
To learn more, see Files and Folders View.
Ability to Access the Installer Session from PowerShell Scripts in Basic MSI and InstallScript MSI Installations
The PowerShell custom action support has been enhanced. It now includes support for several cmdlets that let you interact with the running Basic MSI or InstallScript MSI installation at run time. The cmdlets enable you to get and set Windows Installer properties, expand the value of formatted expressions, and write information to the log file.
With this revised implementation, you can use the Windows Installer property IS_CLR_VERSION to identify a semicolon-delimited list of .NET Framework versions that the custom action should attempt to load to run your PowerShell script.
To learn more, see Calling a PowerShell Custom Action.
Ability to Configure Major Upgrades in Transform Projects and MSI Databases
Transform projects and MSI Database projects now include the Upgrades view, which you can use to create major upgrades. To add an upgrade entry in a Transform project or in direct-edit mode for an MSI Database project, open the Upgrades view. Right-click the Upgrade Windows Installer Setup node and then click Add Major Upgrade Item. Then configure its settings in the right as needed.
To learn more, see:
|•||Adding a Major Upgrade Item|
|•||Preventing the Current Installation from Overwriting a Future Major Version of the Same Product|
Improvements to the ISHiddenProperties Property for Preventing Passwords from Being Written in Advanced UI and Suite/Advanced UI Log Files
The ISHiddenProperties property stores a semicolon-delimited list of case-sensitive property names whose values you do not want to be written to the debug log files. This property enables you to prevent properties that contain passwords and other sensitive information from being logged. The ISHiddenProperties property has been improved. You can now use this property for prevention of logging for values in the following scenarios:
|•||The end user sets the value of the property through command line when launching the Advanced UI or Suite/Advanced UI Setup.exe file.|
|•||The property is configured through a command line that the Advanced UI or Suite/Advanced UI installation passes to a package. This is configurable in the Packages view, on the Common tab, in the Operation area.|
Previously, ISHiddenProperties prevented logging only values that would be logged by changing the property value.
For more information, see Preventing a Property Value from Being Written in Advanced UI and Suite/Advanced UI Debug Log Files.
Improvements to the Interpretation of Ampersands in the Wizard Interface of Advanced UI and Suite/Advanced UI Installations
The interpretation of ampersands in certain areas of the wizard interface of Advanced UI and Suite/Advanced UI projects has been modified.
If you use an ampersand (&) in any of the following areas of the wizard interface of your installation, the installation now displays the ampersand as a literal character instead of interpreting it as a prefix character for a keyboard shortcut. The change also applies if any of these strings include a property that resolves to a value that contains an ampersand.
|•||The string in the header area of a wizard page or secondary window—This is configured in the Title setting for a wizard page or window in the Wizard Interface view.|
|•||The caption bar of wizard pages—This is configured in the Wizard Caption setting for the Wizard Pages node in the Wizard Interface view.|
|•||The supplemental explanation area of a command link control—This is configured in the Note setting for a wizard page or window.|
|•||The alternate text for an image control—This is configured in the Alt Text setting of an image control on a wizard page or window.|
For most label controls, True is now selected by default for the SS_NOPREFIX subsetting under the Style setting; previously False was selected by default. A True value for this subsetting ensures that any ampersands that are included in the string entries for such controls are not inadvertently interpreted as keyboard shortcuts, and that ampersands in the control’s strings are displayed as ampersands in the wizard interface. This applies to the built-in default wizard pages and windows, as well as the predefined wizard pages. The only exceptions to this SS_NOPREFIX subsetting change are label controls that may contain keyboard shortcuts. For example, the default predefined Web Deploy wizard page has several text boxes with corresponding labels that may contain keyboard shortcuts. Therefore, False continues to be default value for the SS_NOPREFIX subsetting of such controls.
The InstallShield Help Library has a new Designating Keyboard Shortcuts and Using Ampersands (&) in the Wizard Interface help topic that explains how to configure your project to support the use of ampersands and keyboard shortcuts in your wizard interface.
Note that when you upgrade an InstallShield 2014 or earlier Advanced UI or Suite/Advanced UI project to InstallShield 2015, many of the aforementioned changes for ampersand interpretation are made automatically made; however, some changes are not made. To learn more, see Upgrading Projects from InstallShield 2014 or Earlier.
Enhanced File-Related Types of Condition Checks Can Search Multiple Target System Paths in Advanced UI and Suite/Advanced UI Installations
When you are building a conditional statement for an exit, detection, eligibility, feature, or wizard interface condition in an Advanced UI or Suite/Advanced UI project, or for an action condition in a Suite/Advanced UI project, you can use the following file-related types of condition checks:
|•||File Exists—This type checks target systems for the presence of a particular file.|
|•||File Comparison—This type checks target systems for specific information—date, version number, or component—for a particular file.|
Both of these condition checks have been expanded to enable you to define conditions that check for the file in multiple paths on target systems. Previously, each condition could check only one specific location on target systems.
To enable this support, the existing Path setting for these condition checks has been expanded to let you enter only the name of the file (that is, optionally now without the path); if you leave out the path, you can use the new Search Path setting to specify a semicolon-delimited list of paths that you want the installation to check at run time for the specified file. You can include in this setting one or more formatted expressions that contain property names, environment variable references, and other special strings; at run time, the installation expands the values of these expressions.
For example, to search for the specified file in all directories that are defined for the PATH environment variable on a target system, as well as the path that is defined in the registry, enter the following value in the Search Path setting:
For more details, see:
|•||File Exists Condition Settings|
|•||File Comparison Condition Settings|
Improvements for Importing InstallShield Prerequisites with Certain Types of File-Related Condition Checks in Advanced UI and Suite/Advanced UI Projects
Advanced UI and Suite/Advanced UI projects now have support for the following conditions that InstallShield prerequisites support:
|•||If you use the condition A file does or does not exist or A file with a certain date exists in a prerequisite and if you reference a registry key within square brackets for part of the path to the file, a Basic MSI, InstallScript, or InstallScript MSI installation resolves the registry key with the registry value. Now that Advanced UI and Suite/Advanced UI installations have expanded formatted-expression support for conditions, these types of prerequisite conditions are properly imported into Advanced UI and Suite/Advanced UI projects and resolved at run time. Previously, the registry key within square brackets was not resolved at run time; therefore, these types of conditions always evaluated as false.|
|•||If you use the condition A file does or does not exist or A file with a certain date exists in a prerequisite and if you omit the path to the file, a Basic MSI, InstallScript, or InstallScript MSI installation searches for the specified file in all directories that are defined for the PATH environment variable on the target system. Now that Advanced UI and Suite/Advanced UI installations have expanded formatted-expression support for conditions, these types of prerequisite conditions are properly imported into Advanced UI and Suite/Advanced UI projects and resolved at run time. Previously, the path to the file could not be resolved; therefore, this type of condition always evaluated as false.|
The InstallShield prerequisites for Oracle Instant Client are examples of prerequisites that use the file-related conditions. Now if you import these types of InstallShield prerequisites into Advanced UI or Suite/Advanced UI projects, those file-related conditions are configured properly in the Detection Condition setting of the Packages view.
For more information, see Including InstallShield Prerequisites (.prq) in an Advanced UI or Suite/Advanced UI Project.
Ability to Upgrade a Project Through the Automation Interface
The automation interface includes support for upgrading a project from an earlier version of InstallShield to the current version. To upgrade a project through the automation interface, use the ForceUpgrade method of the ISWiProject object.
This enhancement is available for the following project types: Advanced UI, Basic MSI, DIM, InstallScript, InstallScript MSI, InstallScript Object, Merge Module, and Suite/Advanced UI.
For more information, see:
|•||ISWiProject Object (Advanced UI and Suite/Advanced UI)|
Ability to Select the Virtual Machine Configuration for a Release Through the Automation Interface
The automation interface has support for selecting the virtual machine configuration for a given release; this enables you to specify which configuration you want to use for distributing the selected release to a virtual machine (VM) at build time.
In Basic MSI, InstallScript, and InstallScript MSI projects, the ISWiReleases object includes several new read-write properties. In Suite/Advanced UI projects, the ISWiSuiteRelease object includes the same new read-write properties.
|•||VMConfig—This property gets or sets the name of the group of VM configuration settings that you want to use when distributing a release to a VM.|
|•||VMSnapShot—This property optionally gets or sets the name of the snapshot that you want to use for distributing the release.|
If no snapshot is specified for the VM configuration, InstallShield does not revert to a specific snapshot. InstallShield powers on the VM without reverting it to a specific snapshot, and copies your installation to the VM.
|•||VMMachineUserName—This property gets or sets the user name for the VM configuration.|
|•||VMMachinePassword—This property gets or sets the password for the VM configuration.|
|•||VMStageMachineCopyPath—This property gets or sets the location on the VM where the release is to be distributed. The last subfolder in the path can be a path that InstallShield creates on the VM; the other folders in the path must already exist.|
|•||VMStagePostBuild—This Boolean property indicates whether you want InstallShield to automatically distribute the selected release each time that it is successfully built.|
This enhancement is available in the Premier edition of InstallShield.
To learn more, see:
|•||ISWiSuiteRelease Object (Advanced UI and Suite/Advanced UI)|
Enhancement to ISICE11
InstallShield internal consistency evaluator 11 (ISICE11) has been improved. If an executable file in your project includes a valid manifest that includes an asm.v2 entry for the trustInfo element, ISICE11 no longer occurs during validation. Previously, the asm.v3 entry was checked, but not the asm.v2 entry.
To learn more, see ISICE11.
Enhanced Dialogs View in Basic MSI, DIM, and Merge Module Projects: All Behavior Settings for Each Control Are Shown in a Single Grid
The Dialogs view has been enhanced. All of the settings that are available for configuring the behavior (events, subscriptions, and conditions) of each user interface control on a run-time dialog are now displayed in a single grid. Previously, the settings were available through separate Events, Subscriptions, and Conditions tabs that were displayed in the bottom-right corner of the view.
To add an event, a subscription, or a condition to a control, in the Dialogs view, select the Behavior node under the dialog that contains the control. The controls that are used on the dialog are displayed in the center pane; select the control that you want to configure. Then use the Events, Subscriptions, and Conditions settings that are displayed in the right pane to configure the appropriate behavior.
This enhancement applies to the following project types: Basic MSI, DIM, Merge Module.
To learn more, see:
|•||Editing Dialog Behavior in Basic MSI Projects|
|•||Using Control Events in Basic MSI Dialogs|
|•||Using Subscriptions in Basic MSI Dialogs|
Enhanced Folder Views Show Total Count of Each Item in the Current Project
The folder views in InstallShield now enable you to see a quick summary of the contents of your project.
For example, the Application Data view—which is the folder view that contains the Files and Folders view and the Redistributables view in some types of projects—indicates the number of files, the number of merge modules, and the number of InstallShield prerequisites that are in the current project. The System Configuration view—which is the folder view that contains views such as Shortcuts and Registry— shows summary data such as the number of shortcuts, the number of registry keys, and the number of registry values.
New Machine-Wide Setting for Removing Unused Components Automatically
The Files View tab on the Options dialog box in InstallShield has a new Clean up unused components check box. This check box lets you specify whether you want InstallShield to remove unused components from your project automatically.
When this check box is selected, you delete all of the files in a component, and that component is not required elsewhere, that component is deleted automatically.
This new check box is a machine-wide setting. This check box is cleared by default; therefore, unused components are not removed automatically by default.
For more information, see Files View Tab.
Enhanced Behavior for Deleting Custom Actions that Use a File in the Binary Table
When you are deleting from your project a custom action that uses a file in the Binary table, InstallShield now determines whether the file in the Binary table is referenced by any other custom actions in the project. If it is not referenced by any other custom actions, InstallShield prompts you to specify whether you want to delete the entry from the Binary table while also deleting the custom action:
|•||The No button, which is the default selection, enables you to delete only the custom action.|
|•||The Yes button enables you to delete both the custom action and the Binary table entry.|
|•||The Cancel button enables you to avoid deleting the custom action and the Binary table entry.|
If one or more other custom actions in the project reference the file in the Binary table, InstallShield deletes only the custom action that you chose to delete; it does not delete the Binary table entry. In this scenario, InstallShield does not display any prompt when you are deleting the custom action.
Previously, when you were deleting a custom action in the aforementioned scenario, InstallShield always displayed a prompt asking whether you wanted to delete the entry in the Binary table—regardless of whether any other custom actions in the project referenced it. The default button on this prompt was Yes, which resulted in both the custom action and the Binary table entry being deleted; this default behavior led to some users inadvertently deleting the Binary table entry.
This enhancement is applicable to the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, and Transform.
New Standalone Build Registry Entries Indicate InstallShield Version Information
The Standalone Build installation now installs the same InstallShield version–related registry values that the InstallShield installation installs under HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\VersionNumber\Professional. This makes it possible to quickly verify whether all of the development and build machines in your environment are using the same versions of the product. The pertinent registry values are:
|•||Product Code—This registry value differs, depending on whether the InstallShield IDE or the Standalone Build is installed. It is updated for major upgrades of these tools.|
|•||MPIndicator—If applicable, this registry value indicates the maintenance pack—for example, Service Pack 1.|
|•||SP—If applicable, this registry value indicates the number of the service pack—for example, 1.|
For InstallShield 2015 and the InstallShield 2015 Standalone Build, the registry values are installed under the following key:
Upgrading Projects from InstallShield 2014 or Earlier
InstallShield 2015 Help Library
|Copyright Information | Contact Us|