InstallShield 2019 Express Edition
New Features
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.
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, or the Requirements view, the Windows 8.1 option has been renamed as Windows 8.1 or Windows 10 to reflect the new run-time behavior.
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.
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.
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 QuickPatch packages. 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.
To learn more, see:
• | Digital Signing and Security |
• | Certificate Selection Dialog Box |
• | Signing Tab (for a release in the Releases 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.
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:
• | HKEY_LOCAL_MACHINE\Software |
• | HKEY_LOCAL_MACHINE\Software\Wow6432Node |
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 the HKEY_LOCAL_MACHINE\SOFTWARE (64-Bit) node in the destination pane in the Registry view. Simply dragging 64-bit data from the source panes in the Registry view to a non-64-bit location in one of the destination panes of the view does not mark the component as 64 bit.
For more information, see:
• | Developing and Building Installations on 32-Bit vs. 64-Bit Systems |
• | Dragging and Dropping Registry Entries to Create Registry Keys |
• | Registry View |
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 Requirements 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.
Enhancements
Performance Improvement for the Files and Folders View
InstallShield has been enhanced to more quickly load the Files view of large projects.
See Also
Upgrading Projects from InstallShield 2014 Express Edition or Earlier
InstallShield 2019 Express Edition Help LibraryApril 2019 |
Copyright Information | Flexera |