Microsoft has finally released the long awaited version of Windows Installer 4.5 that will support pre-vista Operating systems such as Windows XP and Windows 2003. In addition to features packed in MSI 4.0, MSI 4.5 also includes the following enhancements -
- Multiple Package Transaction
- Embedded UI Handler
- Update Supersedence resiliency
- Shared Component Patching resiliency during uninstall
- Custom Action execution on Update Uninstall
More information on MSI 4.5 can be found below -
Windows Installer 4.5 Blog on MSDN
Download Windows Installer 4.5
MSI 4.5 Release Information in KB Article 942288 on MSDN
ClickOnce is a new deployment technology created by Microsoft to ease the deployment of applications over the web. This new deployment technology was first unleashed in 2004 and has quite a fan following. ClickOnce was first shipped with .Net Framework 2.0 and has close integration with .Net applications.
Windows Installer Service is a system level component that allows you to install and manage your applications in a manner consistent and contingent with the Windows Operating System. Windows Installer Service is known for its ability to handle shared and low level system components, while providing setup authors with features that allow them to repair when needed and rollback when installation fails.
Choosing Between ClickOnce and Windows Installer is an article on MSDN that compares the differences between Windows Installer Service and ClickOnce and talks about how the two can complement one another if used together.
ICE a.k.a Internal Consistency Evaluators are a set of rules created by Microsoft to help validate a windows installer package. ICE Rules check the integrity of the package as well as ensure that the Windows Installer best practices were followed when creating an msi package. Before deploying your msi based installation, it is recommended that you ICE validate it.
ICE Rules are stored in files with .Cub extension e.g. darice.cub, shipped by Microsoft contains all the Standard ICE rules that can be run on your package. A .cub file is nothing but a database, just like your msi package and can be edited in Orca. ICE rules behind the scenes are basically Custom Actions that are run on the msi package during the ICE Validation process. You can create your own Custom ICE rules to suit your organizations needs.
You can ICE Validate your msi package with pretty much any tool that allows you to create an msi package e.g. InstallShield 12 or earlier, AdminStudio 8, Wise Package Studio or even Orca.
ICE Validation Best Practices
-
In many cases, ICE Warnings are best practices not followed and ICE errors are issues that can cause the application to not work properly e.g. ICE09 is a warning that states “A component being installed to the Windows Folder is not marked as Permanent” and ICE38 is an Error that states “The Component ‘CompName’ installs to the User Profile. Its key path registry key must fall under HKCU”. If you do not fix the ICE09 warning, setup will attempt to uninstall a component installed in the Windows Folder. However if the component is protected by Windows File Protection, it will not be touched by the msi package, so the repercussion of not fixing an ICE Warning in some cases is not that bad. However in the case on ICE38, if you do not fix it, then subsequent users logging in on the machine will more than likely not get the user profile data being installed by the msi package. Thus it is recommended that you always fix any ICE Errors. ICE Warnings in some cases can be ignored.
-
When creating a Transform to a Vendor MSI package, be sure that your transform does not introduce ICE Errors or warnings in the package. InstallShield Tuner allows you to pre-validate & post-validate a windows installer package when creating a transform. This allows a packager to determine if an ICE error or warning was prevalent in the package or introduced by the transform. It is recommended that only ICEs introduced by a Transform be fixed. You should not fix Vendor package’s preexisting ICE Errors or warnings. Doing so may break the logic used in the vendor package.
Most Common ICEs found in repackaged applications
-
ICE33 – If you repackage an installation with any version of Installshield AdminStudio, you will most certainly see ICE33. This ICE is caused by the fact that repackager adds COM related information into the registry table as supposed to the Microsoft recommended Class ID, Prog ID and Type Lib tables. This Error can be safely ignored as the application should work properly as your com information will be registered via the Registry table.
-
ICE64 – This ICE warns about directories created under the User Profile folder not being specified in the RemoveFile table. So for example if your msi package contains [AppDataFolder]mydir or [PersonalFolder]mysubfolder, ensure that ‘mydir’ & ‘mysubfolder’ are specified in the RemoveFile table. Doing so will ensure that they get removed at uninstallation time.
-
ICE57 – If you have a component in your msi package that contains both per-user & per-machine data e.g if the component is installing a file to [AppDataFolder] and also contains a registry key being installed under HKLM. you can expect to see this Error/Warning. The ideal thing to do is separate User data from machine data into separate components. Anytime you have a component that is installing to a User Profile directory, make sure that the component does not contain a key file. This component should instead have a key path. This component should contain a registry key under the HKCU hive, set as the key path. If your msi package does not contain any registry keys under HKCU hive, create a dummy key to ensure that your user profile data is installed properly for subsequent user logging on the machine.
-
ICE50 – This ICE usually occurs when your installation tool is unable to extract icon from the Icon file specified in the shortcut. Sometimes InstallShield Editor displays this error. The best way to work around it is to specify an Exe or different ico file in the shortcut to extract the icon from.
Microsoft had released about 95+ ICE Errors / Warnings and it is not possible to list them all. However if you have any specific ICE Error or warnings that you are looking for, please comment about it and I will try to blog it.
Category : MSI Engine | Blog
MSI 4.0, the latest version of windows installer service was released with Windows Vista recently. Most of the enhancements in msi 4.0 are in relation to features found in windows vista or Longhorn, e.g. the integration with Restart Manager, ability to communicate with UAC to ensure proper installation on Vista and Longhorn.
In addition to above, Microsoft has also introduced some new properties in msi 4.0 that facilitate setup authors during installation time. You can now set the MsiLogging property via the property table to automatically log the installation. The log file by default gets created in the temp directory on the system. You can change this by setting the MsiLogFileLocation property. A complete list of enhancements can be found on MSDN at : What’s New in Windows Installer 4.0.
Since the enhancements in MSI 4.0 are tied with new features found in Windows Vista and Longhorn, Microsoft is not releasing the redistributables to install msi 4.0 engine alone. Currently the windows installer 4.0 engine is only distributed with Windows Vista and Longhorn.
Category : MSI Engine | Blog