|
|
InstallShield 2008
InstallShield includes the following new features.
InstallShield enables you to specify that your installation requires Windows Server “Longhorn”. It also lets you build Windows Server “Longhorn”–related conditions for features and components.
Note that Windows Vista and Windows Server “Longhorn” use the same major and minor version numbers. Therefore, if you want to use InstallScript to distinguish between Windows Server “Longhorn” and Windows Vista, check whether SYSINFO.nOSProductType = VER_NT_WORKSTATION; for Windows Vista, this is TRUE; for Windows Server “Longhorn”, it is FALSE. For more information, see SYSINFO.
InstallShield now includes many new .NET-related setup prerequisites that you can add to Basic MSI and InstallScript MSI projects:
For more information, see Adding .NET Framework Redistributables to Projects.
An updated Microsoft .NET object is available in InstallShield. This object includes support for versions 1.0 (SP3), 1.1 (SP1), 2.0, and 3.0 of the .NET Framework, including 32-bit, 64-bit x64, and 64-bit Itanium versions. The object also includes all supported language packs, and the latest service packs of 1.0 and 1.1.
In addition, the object launches and completes the .NET Framework installation as the feature containing the .NET object installs. This allows the .NET Framework to be available as early as possible, in case it is needed to install or configure files that are subsequently installed during the installation.
For more information, see Microsoft .NET Object Wizard.
The Windows Installer 3.x Engine object for InstallScript projects now supports 64-bit versions of Windows Installer 3.1. In addition, the object launches and completes the Windows Installer installation when the feature that contains the Windows Installer object is installed. This allows the Windows Installer engine to be available as early as possible, in case it is needed to install or configure files that are subsequently installed during the installation.
For more information, see Windows Installer 3.x Engine Object Wizard.
InstallShield now includes support for IIS 7.
In addition, InstallShield lets you include an SSL certificate for a Web site in your installation. Including an SSL server certificate enables users to authenticate the Web server, check the validity of the Web content, and establish a secure connection.
For more information, see:
InstallShield now enables you to specifically target installations for Windows Embedded CE 6.x. This applies to Basic MSI, InstallScript MSI, and Smart Device projects.
In addition, the Windows Mobile Wizard now enables you to specify configuration XML files for any Windows Mobile device installations. Previously, only Smartphone device installations could include configuration XML files.
InstallShield now enables you to specifically target installations for Windows Mobile 5.0 for Smartphone devices. Previously, you had to select the Smartphone 2003 option if you wanted to include support for Windows Mobile 5.0 for Smartphone devices in your installation. This applies to Basic MSI, InstallScript MSI, and Smart Device projects.
InstallShield now adds to your project the .NET Compact Framework 2.0 SP1 if you select .NET Compact Framework 2.0 in the Windows Mobile Wizard, and if .NET Compact Framework 2.0 SP1 is available on your system. The .NET Compact Framework 2.0 SP1 must be installed, or it must be added to the Support folder in the InstallShield Program Files folder.
This applies to Basic MSI, InstallScript MSI, and Smart Device projects.
InstallShield now includes some new MSXML setup prerequisites that you can add to Basic MSI and InstallScript MSI projects:
To learn more about MSXML, see Run-Time Requirements for XML File Changes.
Two DirectX 9.0c objects are available with InstallShield: a Windows Installer–based object that is available for Basic MSI and InstallScript MSI projects, and an InstallScript-based object that is available for InstallScript projects. Both of these objects install all of the latest DirectX 9.0c core and optional components, including 32-bit-specific and 64-bit-specific components.
In addition, some changes have been made to the DirectX 9 Object Wizard for Basic MSI and InstallScript MSI projects. The wizard now lets you specify whether the redistributable files should be included in the Disk1 folder or streamed into the .msi file. This change enables you to use the DirectX 9 object in compressed installations. Also, you can now use the DirectX 9 object in silent installations.
For Basic MSI and InstallScript MSI projects, the custom action that launches the DirectX installation is now sequenced in the Execute sequence and run in deferred system context so that it can be run with elevated privileges on Windows Vista systems.
To learn more, see:
The MSDE 2000 object for InstallScript projects now contains the MSDE 2000 SP4 files.
For more information about objects, Adding Merge Modules and Objects to Your Project.
You can add a redistributable for FLEXnet Connect 6.1 or 5.x to Basic MSI and InstallScript MSI projects. In addition, you can add a redistributable for FLEXnet Connect 6.0 to InstallScript projects.
The Update Notifications view in Basic MSI and InstallScript MSI projects lets you select which version of FLEXnet Connect you want to include in your project. You can include version 6.1 or any legacy version that is installed in any of the locations that are specified in the Merge Module Location area on the Merge Module tab of the Options dialog box.
The Update Notifications view includes a new Vendor Database setting, which FLEXnet Connect 6.1 supports.
For any new Basic MSI projects that you create, the Install button on the ReadyToInstall dialog now has the User Account Control (UAC) shield icon when the installation is run on Windows Vista systems.
In addition, you can now add the shield icon to any button in a Basic MSI dialog through the Dialog Editor in the Dialogs view. If you are using InstallShield on a Windows Vista system, you can see the shield icon on a button in the Dialog Editor as it will be displayed at run time.
InstallShield now lets you digitally sign any files—including your product’s executable files—in your project at build time. In addition, you can now use a personal information exchange file (.pfx) for digital signatures. All of the following project types support this functionality: Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, Merge Module, and Web.
Note that InstallShield does not support not support using .pfx files to sign media header files (.hdr files), which are used for the One-Click Install type of installation for InstallScript projects. For this type of installation, consider one of the following alternatives:
The new Signing tab in the Releases view is where you specify the digital signature information—including the digital signature files granted to you by a certification authority—that InstallShield should use to sign your files. The Signing tab is also where you specify which files in your installation should be digitally signed. You can also use the Release Wizard to specify all of the digital signature information.
Previously, InstallShield included support for signing only the .msi, .hdr, and Setup.exe files. In addition, InstallShield allowed you to specify .spc and .pvk files for the digital signature, but not .pfx files.
To learn more, see the following:
Dialog themes are predefined sets of images that give your end-user dialogs a unified and distinctive look. With the click of a button, you can now select one of the available themes for your project, and InstallShield applies that theme to all of the interior and exterior dialogs, as well as the Setup.exe initialization dialog, in your project. You can easily preview each dialog from within the Dialogs view to see how it looks with the selected theme.
Some of the themes are available in both the Premier and Professional editions of InstallShield, and some are available in only the Premier edition. For more information, see Available Themes and Corresponding Dialog Sizes.
For more information about this feature, see the Dialog Themes section of this documentation.
The Setup Prerequisite Editor now enables you to specify more details about operating system requirements when you are creating conditions for a prerequisite. The Prerequisite Condition dialog box, which is displayed when you are adding or modifying a condition for a prerequisite through the Setup Prerequisite Editor, lets you select a predefined operating system or select the custom option. With the new custom option, you can configure settings for operating system requirements such as platform, major and minor versions, processor architecture (64-bit or 32-bit), and service pack. If a target system does not meet the operating system requirements, the prerequisite is not installed.
For more information, see the following:
InstallShield includes a set of validators called the InstallShield Best Practice Suite. The InstallShield Best Practice (ISBP) validators in this suite alert you if your installation violates best-practice guidelines.
This feature is available for Basic MSI, InstallScript MSI, and MSI Database projects.
For more information, see:
InstallShield includes support for disabling the Next button on the LicenseAgreement dialog until the end user reaches the end of the End-User License Agreement (EULA) text in the scrollable EULA control through mouse or keyboard scrolling.
The end user must also select the I accept the terms in the license agreement option before the Next button is enabled; this behavior is the same as with earlier releases of InstallShield.
The scroll requirement is not available in the LicenseAgreement dialog by default. To use this functionality, you must add to your project the new Windows Installer DLL custom action called WatchScroll. This custom action calls the EulaScrollWatcher.dll file. In addition, you must modify the Next button’s Control conditions and add an event to the Memo control.
This is available for Basic MSI projects.
For detailed instructions, see Requiring End Users to Scroll Through the EULA in the LicenseAgreement Dialog.
InstallShield now includes support for 64-bit self-registration of COM servers in Basic MSI projects. If you mark a component as 64 bit and then add a file to that component, you can select the file’s Self Register check box to enable 64-bit self-registration of that file during installation. In addition, InstallShield also supports 64-bit self-registration of dynamically linked COM servers. For more information, see:
Support for XML file changes has been expanded in InstallShield:
To learn more, see the following areas:
To learn more about XML file changes, see the Modifying XML Files section of the InstallShield Help Library.
The Required Execution Level setting is now available on the Setup.exe tab in the Releases view for InstallScript projects. Use this setting to specify the minimum level required by your installation’s Setup.exe file for running the installation (the setup launcher) on Windows Vista platforms. InstallShield adds a manifest that specifies the required level.
Previously, InstallShield always included a Highest Available manifest for InstallScript projects, and the Required Execution Level setting was available in only Basic MSI and InstallScript MSI projects.
For more information, see Specifying the Required Execution Level for Your Setup Launcher on Windows Vista Platforms.
If you set a public property in the user interface sequence of an installation that requests elevated privileges for the execute sequence, and you want to pass the property’s value to the execute sequence, the property must be listed as a value for the SecureCustomProperties property, or it must be a restricted public property.
InstallShield now automatically adds to the SecureCustomProperties property properties that may need to be passed from the user interface sequence to the execute sequence. To learn more, see Specifying that a Public Property Should Be a Restricted Public Property.
This support applies to Basic MSI, InstallScript MSI, and Merge Module projects.
To prevent end users from being able to install the current version of your product over a future major version of the same product, the following conditions should be met: The Upgrades view should contain a major upgrade item, the major upgrade item should be properly configured to prevent the current version of your product from being installed over a future version, and your project should include a properly configured and scheduled type 19 custom action.
When you create a new Basic MSI or InstallScript MSI project, InstallShield automatically adds support for preventing the current installation from overwriting a future major version. To learn more, see the following:
Beginning with InstallShield 2008, the ALLUSERS property is set to 1 by default in all new Basic MSI projects. This is the recommended implementation, since most installations must be run in a per-machine context with administrative privileges.
If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2008, InstallShield does not automatically change the value of the ALLUSERS property or add this property if it was not defined in the earlier project.
Also new with InstallShield 2008, by default, the Customer Information dialog in all new Basic MSI projects does not display the radio button group that enables end users to specify whether they want to install the product for all users or for only the current user. This is the recommended implementation for this dialog.
If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2008, InstallShield does not automatically change the Customer Information dialog.
To learn more, see:
The release settings are now organized by category on several different tabs in the Releases view.
In addition, you can now select Compressed or Uncompressed for the Compression setting from within the Releases view. Previously, the only way to modify this setting was to use the Release Wizard. Note that if you want to specify a custom compression setting (one .cab file per feature or one .cab file per component), you must still use the Release Wizard. The Compression setting is available in Basic MSI, InstallScript MSI, Merge Module, and Web projects.
The settings in the Distribution view have been moved to the new Postbuild tab in the Releases view for Basic MSI, InstallScript MSI, Merge Module, and Web projects. The Postbuild tab lets you configure settings for distributing releases to a folder or FTP site automatically at build time.
A new Distribute command is available when you right-click a release in the Releases view for Basic MSI, InstallScript MSI, Merge Module, and Web projects. When you select this command, InstallShield copies all of the relevant files for your release to the locations that are specified on the Postbuild tab. Note that for InstallScript and InstallScript Object projects, InstallShield automatically copies the release to the locations that you specify on the Postbuild tab every time that you build the release.
To learn more, see:
The Custom Actions view and the Sequences view have been combined into a more robust view called the Custom Actions and Sequences view. The combined view supports drag-and-drop editing and copying:
The Custom Actions and Sequences view is available in Basic MSI, InstallScript MSI, MSI Database, Transform, and Web projects.
For more information, see:
Some enhancements have been made to the Shortcuts view for Basic MSI, InstallScript MSI, and merge module projects.
For more details about these enhancements, see:
The -y command-line parameter is available for command-line builds with IsCmdBld.exe and IsSaBld.exe. Use this parameter to specify a product version from the command-line build.
In addition, the InstallShield task for MSBuild now includes a ProductVersion parameter, which you can use to specify the product version through MSBuild. This parameter is exposed as the property InstallShieldProductVersion when the default targets file is used.
Using the -y command-line parameter or the InstallShield task ProductVersion parameter is especially helpful if you want to increment the build version (the third field) of the product version.
To learn more, see:
The -z command-line parameter is available for command-line builds with IsCmdBld.exe and IsSaBld.exe. Use this parameter to override the value of a Windows Installer property or create the property if it does not exist.
To learn more, see:
Several enhancements are available for the Files and Folders view:
The Registry view also has a new link (either Show Source Panes or Hide Source Panes) in the upper-right corner. Use this new link to show or hide the two top panes—the Source computer’s folders pane and the Source computer’s files pane—in this view.
Two enhancements have also been made to the Redistributables view for Basic MSI and InstallScript MSI projects:
You can configure an IIS Web server to prevent the CMD command for the #exec directive from being used to execute shell commands, or you can configure it to allow the CMD command to be used to execute this type of command. The SSIEnableCmdDirective registry value for the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters registry key is what determines whether the CMD command is permitted.
The Internet Information Services view in InstallShield includes a new SSIEnableCmdDirective registry value setting. This setting lets you specify how your installation should configure the SSIEnableCmdDirective registry value on target systems. This setting also lets you specify that the SSIEnableCmdDirective registry value should not be changed at installation run time; this is the default behavior.
For more information, see Specifying Whether a Web Server Should Allow the CMD Command to Be Used for SSI #exec Directives.
You can now use the new Host Header Name setting on the Web Site tab for a Web site in the Internet Information Services view to specify the host header name that identifies the IIS Web site that is installed during your installation. Previously, it was necessary to configure the ServerBindings property on the Advanced tab in this view in order to specify the host header name.
For more information, see Specifying the IIS Host Header Name for a Web Site.
A new SQL Scripts tab on the Options dialog box lets you specify how InstallShield should create new database connections by default—either by using the same Windows Installer properties that were used by default for the first connection in your project, or by using a unique set of new Windows Installer properties.
This applies to the following project types: Basic MSI and InstallScript MSI.
For more information, see the following:
The SQLLogin dialog now includes a new control that enables end users to specify the name of the target database catalog. This dialog also has a Browse button next to the new control; the Browse button lets end users select from the list of database catalogs that are available on the target database server.
If you upgrade a Basic MSI project that includes SQL support from InstallShield 12 or earlier to InstallShield 2008, you need to manually import the SQLLogin.isd and SQLBrowse.isd dialogs into your project to use the new version of the SQLLogin dialog. The .isd files are installed in the following location by default: C:\Program Files\Macrovision\IS2008\Support. To use this updated SQLLogin dialog in InstallScript and InstallScript MSI projects, replace the SQLServerSelectLogin function call in your InstallScript code with a call to the new SQLServerSelectLogin2 function.
The Database Import Wizard has a new Advanced Scripting Options panel that lets you specify security script options such as script database, script database users and database roles, script SQL Server logins, and script object-level permissions.
For more information, see Advanced Scripting Options Panel.
InstallShield includes support for a new Windows Installer property called IS_SQLSERVER_CXNS_ABSENT_FROM_INSTALL. Use this property to specify one or more SQL connections that should be skipped during installation or uninstallation. To specify more than one SQL connection, separate each with a semicolon (;). To skip all of the SQL connections, set the value of this property to ALL. Using this property is helpful if you cannot uninstall a product because of a SQL scripting error.
For details about SQL-related properties, see Overriding the Default SQL Run-Time Behavior.
The Build tab in the Releases view includes a new Keep Unused Directories setting. Use this setting to specify whether you want InstallShield to remove unused directories from the Directory table of the .msi file when you build the selected release. The default value is No.
This setting is available for Basic MSI, InstallScript MSI, and Merge Module projects.
For more information, see Build Tab.
Merge Module projects now include the DIM References view, which was previously available in only Basic MSI projects. The DIM References view lets you add .dim files that were created with InstallShield Collaboration or InstallAnywhere Collaboration to your project.
InstallShield enables you to add a merge module that contains .dim files to any project type that supports merge modules—for example, Basic MSI, InstallScript, and Direct MSI projects. You can also add a merge module that contains .dim files to another merge module as a dependency.
For more information, see:
The Component Services view has two new Destination fields on the Installation tab: one for a server type of installation, and one for a proxy type of installation. Use these fields to specify the target destination of the selected COM+ component files. Previously, the only way to specify the destination of the components associated with a COM+ application was in the Components view or the Setup Design view.
InstallShield includes support for a new Windows Installer property called IS_COMPLUS_INSTALL_AT_FINALIZE. Use this property to specify one or more COM+ applications that should be installed by the ISComponentServiceFinalize action, which is called after the InstallFinalize action. To specify more than one COM+ application, separate each with a semicolon (;). To specify that all COM+ applications should be installed by the ISComponentServiceFinalize action, set the value of this property to ALL.
Using this property is helpful if you want to install a COM+ application that contains .NET assemblies to be installed to the GAC because Windows Installer does not commit the changes made in the in-script session to the GAC until the InstallFinalize action.
InstallShield has several new predefined system searches:
If your installation requires any of these products, you can use the System Search view or the Installation Requirements page in the Project Assistant to add 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.
Many enhancements have been made to the automation interface.
You can now save an InstallShield 2008 project as an InstallShield 12 project (.ism) through the automation interface by using the new epv120 value for the PropertySchemaVersion property of the ISWiProject object. For more information, see the description of the PropertySchemaVersion property.
The CreateProject method for the ISWiProject object now enables you to create merge module projects. Previously, this method supported only Basic MSI, InstallScript, InstallScript MSI, and InstallScript Object projects.
To learn more, see CreateProject Method.
The automation interface includes a new object and a new collection for dynamic file links. In addition, the ISWiComponent object includes two new methods and a property that let you add (AddDynamicFileLinking) and remove (RemoveDynamicFileLinking) a component’s dynamic file link, as well as get the collection of dynamic file links (ISWiDynamicFileLinkings).
For more details, see:
The automation interface includes a new object and a new collection for configuring path variables in a project. In addition, the ISWiProject object includes two new methods and a property that let you add (AddPathVariable) and remove (DeletePathVariable) a path variable from a project, as well as get the collection of path variables (ISWiPathVariables).
To learn more, see:
The automation interface includes new objects and collections for configuring languages and string entries in a project. The ISWiLanguage object includes two methods and a property that let you add (AddStringEntry) and remove (DeleteStringEntry) a string entry from a project, as well as get the collection of string entries (ISWiStringEntries). In addition, the ISWiProject object includes a new property (ISWiLanguages) that gets the collection of languages included in the current project.
For more information, see:
The automation interface includes a new object and a new collection for environment variables. In addition, the ISWiComponent object includes two new methods and a property that let you add (AddEnvironmentVar) and remove (RemoveEnvironmentVar) a component’s environment variables, as well as get the collection of environment variables (ISWiEnvironmentVars).
The ISWiProject object includes several new properties that let you specify values for General Information view settings:
The ISWiRelease object includes several new properties that enable you to configure settings for digitally signing files for releases at build time. The new properties are:
The ISWiRelease object includes a new KeepUnusedDirectories property that lets you specify whether you want to want InstallShield to remove unused directories from the Directory table of the .msi file when you build this release.
The ISWiRelease object includes a new DotNetDelayReboot property that lets you specify whether you want to postpone any reboot associated with installing or updating the .NET Framework on the target system until after your installation has completed.
The ISWiRelease object includes a new DisplayDotNetOptionDialog property. Use this property to specify if a message box should be displayed at run time to let end users indicate whether the .NET Framework should be installed.
The ISWiRelease object now includes several new properties that enable you to configure settings for distributing releases to a folder or FTP site automatically at build time. The new properties are:
The ISWiSequence collection has a new RemoveSequenceRecord method that enables you to delete an item from a sequence. To learn more, see RemoveSequenceRecord Method.
The automation interface now includes support for the ISWiSetupFile and ISWiAdvancedFile objects in Basic MSI projects. These objects include methods (AddSetupFile, DeleteSetupFile, AddAdvancedFile, and DeleteAdvancedFile) that are now available in Basic MSI projects. Previously, these objects and methods were available in only InstallScript, InstallScript MSI, and InstallScript Object projects.
To learn more, see:
One-Click Install installations in InstallScript projects can now be used on Windows Vista systems and with Internet Explorer 7. The One-Click Install setup player is now an external .ocx file, instead of being embedded in the Setup.exe file. The setup player downloads and then launches the Setup.exe file with the appropriate command line. This enables end users who are using Windows Vista with limited privileges to run the installation; if elevated privileges are required because of the required execution level specified in the installation’s manifest, the appropriate User Account Control (UAC) prompt is displayed when the Setup.exe file is launched.
To support this new behavior, a new Generate One-Click Install setting is available on the Internet tab in the Releases view and on the Internet Options panel in the Release Wizard. If you select Yes for this setting, InstallShield includes an .ocx file for the installation.
To learn more about One-Click Install installations, see the Typical Web Installation vs. One-Click Install section of the documentation. In addition, see the following:
Two new command-line parameters are available for Setup.exe and Update.exe:
In addition, the /L parameter now supports both hex and decimal language values.
To learn more, see Setup.exe and Update.exe Command-Line Parameters.
The Downloader type of Web release now lets you specify whether InstallShield should create external .cab files that are downloaded at installation time as needed. Previously, .cab files were always streamed into the .msi package for the Downloader Web release type.
The new external .cab file options are available on the Downloader Options panel of the Release Wizard. This panel is displayed in the Release Wizard if the media type is Web and the Web type is Downloader. The Downloader Options panel has a new Create external .cab files check box. If you clear this check box, the behavior is the same as it was previously: the .cab files are streamed into the .msi package. If you select this check box, you can specify how .cab files should be created: one .cab file per feature, one .cab file per component, or multiple .cab files based on a particular size that you specify.
The Downloader type of Web release and the Install from the Web type of Web release now always embed all .mst and .ini files in the Setup.exe file.
The Identification tab, which was previously called the Uninstall tab, is where you specify information that should be displayed for a patch in Add or Remove Programs on systems running Windows Installer 3.0 or later. This tab in the Patch Design view of Basic MSI and InstallScript MSI projects and in the General Information view in QuickPatch projects has settings for items such as the display name, the manufacturer name, and the support URL. Now every time that you change the latest setup for a patch configuration in the Patch Design view or in a QuickPatch project, InstallShield uses the Add or Remove Programs information from the latest setup as the values for the Identification tab settings. You can override the values on the Identification tab as needed.
In addition, the Allow Patch to Be Uninstalled (Requires Windows Installer 3.0) check box is now available on the Common tab. This setting was previously available on the Uninstall tab.
For more information, see:
Several enhancements have been made to the InstallScript language.
The LaunchApplication function uses either the Windows API function CreateProcess or the Windows API function ShellExecuteEx to launch the specified application. After the application is launched, the installation can optionally call the new WaitForApplication function to wait for the application to terminate.
The WaitForApplication function waits for a running application, and optionally all child applications that are launched by the running application, to terminate before returning.
Note that calling LaunchAppAndWait now calls the following:
LaunchApplication( szProgram, szCmdLine, "", LAAW_STARTUPINFO.wShowWindow, LAAW_PARAMETERS.nTimeOut, nOptions | LAAW_OPTION_CHANGEDIRECTORY | LAAW_OPTION_FIXUP_PROGRAM );
The new LaunchApplicationInit function is available. This function, which was added to match the naming convention of the LaunchApplication function, has the same behavior as the LaunchAppAndWaitInitStartupInfo function.
For more information, see:
Several new predefined constants are available:
In addition, the LAAW_OPTION_NO_CHANGEDIRECTORY is now obsolete. Passing this parameter has no effect.
The following script variables are also now available:
A new SdRMFilesInUse function is available. This function displays a dialog that includes a list box containing a list of the applications that are open and are locking files. The dialog also includes two radio buttons that allow end users to specify whether the installation should attempt to use the Restart Manager to shut down the applications that are locking files or overwrite the locked files (which most likely results in the need for a reboot to complete the installation).
For InstallScript MSI projects, the new OnRMFilesInUse event handler displays the new SdRMFilesInUse dialog. This event handler is called when the Restart Manager is enabled and Windows Installer 4.0 sends an INSTALLMESSAGE_RMFILESINUSE message to the installation.
For more details, see:
The Compile/Link tab on the Settings dialog box, which is available from the Build menu in InstallShield, now has an Include Paths box. Use this Include Paths box to specify which directories InstallShield should search for source files that have been included in the main installation’s InstallScript code through #include statements. It corresponds with the -i option for Compile.exe, the command-line compiler.
To learn more, see Compile/Link Tab.
A new FOLDER_DOTNET_30 InstallScript variable is available. This variable stores the path of the .NET Framework 3.0. The corresponding text substitution for this variable is <FOLDER_DOTNET_30>.
The .NET Framework 3.0 writes the value InstallSuccess with value data of 1 to the registry to indicate that it is installed. To support this new possible registry value, the Is( DOTNETFRAMEWORKINSTALLED ) function has been enhanced to also check for the new value InstallSuccess. The Is( DOTNETFRAMEWORKINSTALLED ) function also still checks for the value of Install, which is used by earlier versions of the .NET Framework. For more information, see Is.
Two new constants are available for use with the Is function:
Use the new DOTNETSERVICEPACKINSTALLED constant with the Is function to determine whether a particular service pack—or a later version of the service pack—of the .NET Framework is installed. For more information, see Is.
Several InstallScript functions for SQL support have been added or updated.
The following InstallScript functions are now available for InstallScript and InstallScript MSI projects:
The following InstallScript functions are now available for InstallScript projects:
The following InstallScript function is now available for InstallScript MSI projects:
The following InstallScript functions, which were previously available only for InstallScript projects, are now also available for InstallScript MSI projects:
InstallShield still supports the functions that are superseded by new versions of the functions. However, if you upgrade a project that was created in InstallShield 12 or earlier to InstallShield 2008, InstallShield does not automatically update the existing InstallScript code to use the new functions.
For more information, see:
Use the new USER_INADMINGROUP constant with the Is function to determine whether a user is in the Administrators group, regardless of whether that user is running the installation with a standard access token. For more information, see Is.
Note that Is( USER_ADMINISTRATOR ) now returns FALSE if the user is in the Administrators group but the group has the SE_GROUP_USE_FOR_DENY_ONLY security identifier (SID) attribute set (that is, the user is running with a standard access token).
Two new InstallScript functions are available: DotNetCoCreateObject and DotNetUnloadAppDomain.
The DotNetCoCreateObject function is similar to the CoCreateObjectDotNet function. The only difference is that with DotNetCoCreateObject, you can specify the .NET application domain that should be loaded; the assembly is then run in this domain.
For CoCreateObjectDotNet, the .NET assembly is loaded into the default application domain after the installation completes; thus, the .NET assembly file is locked until the installation has finished.
A new UpdateServiceOnEnabledStateChange function is available for InstallScript projects. This function lets you to enable the update notification support for an upgrade if your original base installation did not include FLEXnet Connect files.
A call to UpdateServiceOnEnabledStateChange was added to the OnUpdateUIBefore event handler; therefore, if you previously customized this event in InstallShield 12 or earlier and then migrate your project to InstallShield 2008, you must add the new code to your custom override of the event. It is not added automatically.
To learn more about this function, including when it is called at run time, see UpdateServiceOnEnabledStateChange.
A new InstallScript function called RegDBDeleteItem is now available. The RegDBDeleteItem function deletes values under the per application paths key or the application uninstallation key, depending on the value of nItem. For more information, see RegDBDeleteItem.
A new InstallScript function called GetStatus is now available for InstallScript Object projects. The GetStatus function retrieves the current status of the object; that is, the current value of Status.Number. For more information, see GetStatus.
The LWTF_OPTION_APPEND_TO_FILE constant has been added to the InstallScript language. You can pass this constant as the nOptions parameter for the ListWriteToFileEx function to append a list to an existing file.
In addition, two existing nOptions constants have been renamed:
To maintain backwards compatibility, the aforementioned two LWFT_* constants are still available, and they are defined the same way as the corresponding new LWTF_* constants.
For more information, see the following:
See Also
Upgrading Projects from InstallShield 12 or Earlier
Upgrading Projects from InstallShield 11.5 or Earlier
|
|
Copyright Information | Contact Macrovision |