View Full Version : InstallScript Redesign

Christopher Painter
03-27-2006, 06:57 PM
I've been reading the release notes and I'm eagar to put the new scripting engine to it's paces. Hopefully this will overcome the resistance I've encountered to InstallScript.

03-27-2006, 10:44 PM
I haven't installed yet, will do soon, however, are the release notes available in another location I can access before installing?

Christopher Painter
03-28-2006, 02:50 AM
I've played with it and I like it, but I wonder a couple things:

1) We tend to try to componentize everything we do. It would be interesting to have scripts get compiled into DLL's and shared using merge modules. I used ORCA to export the compiled DLL and load it into a dummy MSI and it worked. But the TARGET function names of "f1" was not intuitive.

2) If we put compiled custom actions into merge modules this way the install would grow massive in size as each DLL seems to have a base size of around 3mb. It would be interesting to put the real engine in SUPPORTDIR and have just a tiny stub in the binary table that contains the resources and loader.

03-28-2006, 11:58 AM
Unfortunately those are both hard to address. Changing the f1/f2/... entry points would require tweaking ISSetup.dll at build time to have more informative names. While I'm sure there's some way to do it, I'm not sure there's any realistic way to do so, and I certainly wouldn't expect it in time for this release. In the meantime you can look up the real names in the MSI.

As for the size vs. storing the file outside the merge module, we can't store the engine in the consuming MSI without giving up the new standalone benefits of these merge modules: you can now theoretically create a merge module with InstallScript actions, and consume it anywhere from previous versions of our product to our competitors' products. We might be able to optimize that if we detect identical versions, but that's for later. While there may be some general size savings available, right now our focus is on making everything work every bit as well or better than it did; size comes second.

Mike Marino
03-28-2006, 12:16 PM
Here is the New Feature Section of the Release notes...

New Features

Ability to Target Windows Vista Systems
InstallShield enables you to specify that your installation requires Windows Vista. It also lets you build Windows Vista—related conditions for features and components.

Validation for the Windows Vista Quality Program
To provide the best possible installation experience for end users, ensure that your installation follows the best practices outlined in the Windows Vista Quality Program. InstallShield now includes a validation suite that helps you verify that your installation meets the Windows Vista Quality Program requirements for Basic MSI projects. If you want to be able to use the Windows Vista Logo artwork, your application's installation must meet the program's requirements.

In addition, InstallShield now lets you customize the list of internal consistency evaluators (ICEs) that should be used for installation package validation and merge module validation. This is helpful if you do not want to pursue logo certification but you still want to ensure that your installation or merge module meets specific best practices that are verified during validation.

Note that by default, releases are validated every time that they are built. To change this behavior so that validation is performed only on demand from the Build menu, use the Validation tab on the Options dialog box.

User Account Control Support
InstallShield includes support for the User Account Control functionality that Microsoft added for Windows Vista. Use the new Require Administrative Privileges setting in the General Information view to specify at a project-wide basis whether administrative privileges are required for an installation. Use the new administrative privileges check box on the new Behavior tab in the Setup Prerequisite Editor if a prerequisite requires it. Also, use the Required Execution Level setting in the Releases view to specify the minimum level required by your installation's Setup.exe file for running the installation's setup prerequisites on Windows Vista platforms.

Support for Minimizing Reboots Through the Restart Manager Infrastructure
Restarting the system after an installation is inconvenient for end users. One of the Windows Vista Quality Program requirements is that all installations must contain an option that enables end users to automatically close applications and attempt to restart them after the installation is complete.

To support this quality guideline, an MsiRMFilesInUse dialog is available in all Basic MSI projects. The installation displays this dialog if one or more files that needs to be updated are currently in use during the installation. The dialog contains two options to allow end users to specify how to proceed:

End users can choose to have the installation close the applications that are using those files and then attempt to restart the applications after the installation is complete.
End users can avoid closing the applications. A reboot will be required at the end of the installation.

Digital Signature Enhancements
InstallShield enables you to digitally sign your installation. During build time, InstallShield adds the necessary information to the MsiDigitalCertificate table. This enables end users to apply patches without having administrative privileges. You can edit the MsiDigitalCertificate table through the Direct Editor to stream in an external digital certificate. In addition, the Build Installation page in the Project Assistant now offers the ability to digitally sign your installation.

Support for Documentation about Custom Action Behavior
The intended behavior of each custom action must be documented for the Windows Vista Quality Program. This is especially helpful if system administrators deploy your product to enterprise environments; they sometimes need to know what the custom actions do. InstallShield now has a new Help File Path setting in the Custom Actions view to help you meet this requirement. Use this setting to specify the path of a document that describes the behavior of a custom action that you create for your project. The InstallShield Help Library now describes the built-in InstallShield custom actions are automatically to InstallShield projects to support different functionality.

Windows Installer Log File Support
InstallShield provides support for the option to easily log installations run with Windows Installer 4.0 on a project-wide basis without having to use the command line or configure log parameters through the registry. To enable logging, specify Yes in the new Create MSI Logs setting in the General Information view. To override the default logging parameters, edit the MsiLogging property in the Property Manager view. If the installation is run on a target system that has Windows Installer 4.0, the installer creates a log file and populates the MsiLogFileLocation property with its path. In addition, a Show the Windows Installer log check box is added to the SetupCompleteSuccess, SetupCompleteError, and SetupInterrupted dialogs.

Setup Prerequisite Enhancements
Many enhancements have been made to the Setup Prerequisite Editor:

The user interface has been improved; it now has menus that list easy-to-access commands.
The new Behavior tab lets you specify whether end users may skip the prerequisite installation, whether the prerequisite requires administrative privileges, and how the prerequisite installation should proceed if it appears that the target machine does or does not need to be restarted.
Now you can create prerequisite installation conditions for DWORD registry comparisons. You can also create conditions for 64-bit machines.
Redistributing setup prerequisites is now more flexible than ever. You can specify different methods for supplying each individual setup prerequisite in your installation. This enables you to store some of the setup prerequisite files on the source media; compress some of the setup prerequisite files into Setup.exe, to be extracted at run time; and download some of the setup prerequisite files. In addition, you can now assign release flags to setup prerequisites. Then you can include and exclude any combinations of setup prerequisites when you build different releases.

Pocket PC Windows Mobile 5.0 and Windows CE .NET 5.0 Support
InstallShield now enables you to specifically target installations for Pocket PC Windows Mobile 5.0 and Windows CE .NET 5.0 mobile devices.

.NET Compact Framework 2.0 and Other Mobile Device Redistributables Now Available
Several new redistributables are available for mobile device installations: .NET Compact Framework 2.0, SQL Mobile 2005, SQL Client 2.0, and SQL Mobile 2005 Replication. In addition, installations for Smartphone 2002 and 2003 now support redistributables.

Expanded Digital Signing for Mobile Devices
All mobile device platforms now support digital signing. Previously, digital signing was available for Smartphone 2002 and 2003 only.

Repackager Project Conversion Tool Available in Premier Edition
Installations created for the Windows Installer service dramatically differ from traditional installations, making it impossible to reuse legacy installations without a repackaging tool. Repackager assists you by capturing the data placed on your system during installation and converting it into a Windows Installer package, which you can then customize and distribute according to your organization's needs. To learn more, see the help library that is included with this tool.

Additional InstallShield Collaboration Licenses for Premier Edition
InstallShield Premier Edition now includes a five-pack of licenses for InstallShield Collaboration for Visual Studio. You can use these licenses to install InstallShield Collaboration on development systems that do not have InstallShield but do have Visual Studio .NET 2002, Visual Studio .NET 2003, or Visual Studio 2005.

DIFx 2.01 Support
InstallShield includes support for the latest version of Driver Install Frameworks for Applications (DIFx). This new version includes the latest binary files from Microsoft. This new version is available for any Basic MSI, InstallScript, or InstallScript MSI projects that you create in InstallShield.

InstallScript Rearchitecture Enhancements for InstallScript MSI Projects and Basic MSI Projects with InstallScript Custom Actions
The InstallScript MSI architecture has had a number of issues with security (COM/DCOM) and other areas that can cause some installations to fail for various reasons. The architecture has been improved dramatically for InstallShield 12 to resolve these issues and to make InstallScript MSI a more reliable project type. The improvements also help increase the reliability of Basic MSI projects that include InstallScript custom actions.

Internet Explorer 7.0 Compatibility
Several areas of InstallShield have been revised so that it is now compatible with Internet Explorer 7.0. The Transform Wizard, Custom Action Wizard, the String Table Editor, the Distribute view, and the General Information view are all examples of areas that have been updated.

Authenticating Proxy Support for Online Activation of Trialware
Online activation of the Try and Buy type of trialware that is created with InstallShield has been enhanced to allow end users to perform online activations when they are accessing the Internet through a proxy server. Therefore, you can now perform an online activation of InstallShield through an authenticating proxy server. In addition, if you have an InstallShield Activation Service account and you use InstallShield 12 to create the Try and Buy type of trialware for your product, your end users can activate your trialware through an authenticating proxy server.

Enhanced Start Page
The list of recently opened projects that are displayed on the Start Page now includes a column that shows the project type. In addition, the maximum number of projects that are listed has been increased from four to eight.

Christopher Painter
03-30-2006, 02:59 PM

Does InstallScript have a For..Each enumerator yet? I've been using the one off of InstallSite but it would be really nice to have that built into the language. I don't see how any COM client implementation could be complete without it.

Stefan Krueger
04-05-2006, 08:47 AM
In general I like the idea of improving InstallScript support for custom actions. One thing that concerns me is that the change for global variables will break some existing projects when they are migrated to the new version. Ideally you should provide some other way to persist variable values between function calls. Or include a "compatibility mode" that uses the old architecture.

Packaging the InstalLScript engine for each custom action will not only increase the size of the msi file but may also slow down the instalaltion because the engine needs to be extracted to the temp folder multiple times.

What happens if different custom actions use different versions of the scripting engine (e.g. CAs in merge modules)? Will Windows Installer load the matching version of idriver.dll into memory? You will probably need to make sure each version has a different name, otherwise Windows Installer might re-use a previously loaded DLL.

Mike Marino
04-05-2006, 10:02 AM
The Script Engine itself is only included once per MSI. This is the same overhead one would incur in the past (unless the user was selecting to download the Script engine).

Global Variables will only break in the case where they are used between InstallScript Custom Actions. You can still use them in InstallScript MSI projects (with one exception, InstallScript MSI with InstallScript custom actions, the custom actions cannot seen any global variables).

We are doing some performance testing to see what the impact of engine decompression is. In our informal tests, the engine decompression time was very small, and did not seem to noticeably slow down installation.

Thanks for the feedback.

Christopher Painter
04-05-2006, 10:10 AM

What if a developer made a merge module using IS12 and included ISScript CA's. Then later a developer consumed that merge module using IS12.5 without rebuilding the merge module that was in his merge module repository. Wouldn't that result in an MSI that contained

a) 2 different instances of the script engine in the binary table
b) 2 different versions of the script engine that could conflict with each other as Stefan suggests.

Stefan Krueger
04-05-2006, 10:30 AM
[QUOTE=Mike Marino]Global Variables will only break in the case where they are used between InstallScript Custom Actions. You can still use them in InstallScript MSI projects (with one exception, InstallScript MSI with InstallScript custom actions, the custom actions cannot seen any global variables).[QUOTE]We still need to assist developers who have used them this way. Passing values to deferred custom actions come to mind specifically. At the very minimum warn them during project conversion.

04-05-2006, 11:14 AM

The script engine is loaded\unloaded with each custom action, so there should not be conflicting versions of the engine loaded at any given time. Even if you consumed a 12.0 merge module in a 11.5 project for example, it will still work because the old architecture loaded the script engine in IDriver.exe process, not the msiexec.exe process. This is the biggest change in that there is no longer any additional process, everything is run inproc.

If you have a 12.5 project which contains both 12.0 and 12.5 custom actions, you will in fact have the extra overhead of the two versions of the engines, but the script engine again will be loaded\unloaded upon execution of each custom action so it doesn't matter if you mix 12.0 CAs with 12.5 CAs (or any other version for that matter).

In regards to global variables, existing InstallScript MSI projects should not be affected in any way if you have code that is only called from one of the events because all of the events are called external to the MSI, from the same instance of the script engine. The problem comes when you add Custom Actions that are called from the MSI. By default, new & upgraded projects have no MSI custom actions (unless they were added by the user previously - pretty rare, no???).

Let me know if this is not clear or if you have additional questions\concerns.... It's kind of hard to explain it all in a paragraph or two :), but I'd be happy to answer any other specific questions related to this.

Stefan Krueger
04-05-2006, 11:29 AM
The script engine is loaded\unloaded with each custom action
I believe I've seen problem reports (not related to InstallScript) where a DLL custom action was used, and when a Major Upgrade was performed the old version of that custom action DLL was used not only for the uninstall of the old version but also during the instalaltion of the new version, because a DLL with the same name was already loaded in the msiexec process (workaround is to rename the dll). You don't want that to happen with idriver.dll.

By default, new & upgraded projects have no MSI custom actions (unless they were added by the user previously - pretty rare, no???).
I was talking about (deferred) InstallScript custom actions in a Basic MSI project.

Christopher Painter
04-05-2006, 11:31 AM

You said the engine is loaded and unloaded. Is there any chance an ansyc CA could have a 1 version of the engine loaded and a second custom action fires sync expecting a different version of the engine but windows gives it a handle to the first? Also same question for 2 sync custom action where the first custom action somehow fails to unload the module.

Also if I have a project that consumes 3 merge modules and each merge module contains a custom action (lets say same version ) will I end up with 3 different engines in my built MSI project?

04-06-2006, 09:13 AM
We are doing some performance testing to see what the impact of engine decompression is. In our informal tests, the engine decompression time was very small, and did not seem to noticeably slow down installation.

Thanks for the feedback.

My $.02! No one is using an installer as an application, therefore I could care less how fast the installation occurs. Granted, if it takes 30 minutes instead of 10 minutes, yeah, could be a concern. However, what I DO care about is the size of my downloads. I pay for bandwidth, I don't pay for time of installation. Smallest downloadables is more important to me. Maybe you can have an option like in some programming languages "Compile for Fast Code" or "Compile for Small Code". But some people that write software don't have a concept in other costs of a business, i.e. that bandwidth is not cheap, and it's something we have to pay for! Download on demand is something I'd like to see improved such as in a Install From the Web type scenario, where only required CAB's are downloaded, not the entire installation. The installer should poll the system prior to initiating the install to see what's required. If the system already has DAO, why download it? We need "smart" installers!!!