• Sidebar: What Happens During Application Installation?
• Sidebar: Prior Installation Technology Improvements
• Sidebar: Windows Installer Overview
• Sidebar: Shared Side-by-Side .NET and Win32 Components

Microsoft has further improved Windows to address the difficulty many business customers have with distributing and installing "thick"-client applications. A new version of the Windows Installer service provides support for new installation tasks, and the .NET Framework and improvements to the way shared components are supported in Windows XP ease "DLL Hell" issues created during application installation. However, application installation is still not easy, and the so-called XCOPY deployment promised for applications that run under the .NET Framework still has limitations that might prevent it from being a practical means of deploying and installing client-side applications.

This article deals solely with client-side software installation; improvements to Microsoft’s software distribution products and server-based application installation are not covered. Also, this article covers application installation only; none of the new features in Windows XP or Windows Server 2003 (formerly known as Windows .NET Server 2003) affects the way that components or patches for operating-systems (OSs) get installed.

Supporting Thick-Client Installation

Users often prefer client-side applications (often referred to as "thick," "fat," "smart," or "rich" clients) to so-called thin clients (browsers or terminal service clients that interact with applications running on servers) because thick clients usually offer the following:

• Faster response to user input or requests
• Superior user interface
• Some degree of functionality when offline.

However, organizations often prefer thin clients so they can avoid the distribution, installation, and maintenance headaches associated with thick clients. Although software distribution tools, such as Microsoft’s Systems Management Server (SMS), help get software onto a client computer and their setup programs launched, the initial installation and ongoing maintenance are complex, error-prone processes. (For an overview of the installation process, see the sidebar "What Happens During Application Installation?".) Consequently, application installation and maintenance are frequent sources of bugs. Chief among these bugs: installing an application that shares components with applications already on the machine frequently breaks the existing applications, a condition dubbed "DLL Hell" after the dynamic link library (DLL) files in which shared components are delivered.

Microsoft recognized that it had to make the installation process easier and more robust for Windows to stay relevant and vital as a client OS. Microsoft introduced two technologies around the time Windows 2000 shipped that began to tackle these issues:

Windows Installer. Code-named Darwin, Windows Installer provides a single utility that handles many of the complexities of application installation and maintenance, simplifying installation for application developers. Shipped in Windows 2000, Windows Installer is also available for Windows 98 and NT 4.0.

Side-by-side components. Windows 2000 introduced a way for applications to use private versioned components, which installation of other applications cannot alter. Developers can use this mechanism to reduce the probability of DLL Hell with their applications.

(For background on these advances, see the sidebar "Prior Installation Technology Improvements".)

Microsoft has improved both of these technologies in Windows XP and in the upcoming release of Windows Server 2003. Windows XP shipped with a substantially improved version of Windows Installer. With the release of the .NET Framework run-time system in Feb. 2002, Microsoft enabled a new class of "managed code applications" that are somewhat easier to install and maintain than Win32 or COM applications. The new OSs also support a new mechanism for side-by-side shared components with Win32 and COM applications, and many of Microsoft's own shared components take advantage of this mechanism, further reducing the risk of DLL Hell. However, despite all these improvements, installation of client-side applications is still a complex process that relies on the application developer to code all the tasks that must be performed during installation. Even installation of .NET Framework applications is still more complex than Microsoft’s claims of "XCOPY deployment" (the practice of copying all of an application’s components into a single directory and executing it from there without further ado, often accomplished in MS-DOS days with the XCOPY utility) might suggest.

What’s New in Windows Installer 2.0?

Windows Installer 2.0 is the latest version of Windows Installer, the service responsible for installing and uninstalling Windows Installer–based application packages (i.e., those that use the .msi extension). Windows Installer 2.0 comes with Windows XP and Windows Server 2003, and Windows 2000 Service Pack 3 also upgrades older Windows Installers to the new version. Windows Installer 2.0 can also be redistributed with applications for Windows 9x and NT 4.0 Service Pack 6 systems.

Windows Installer 2.0 adds new capabilities and removes some limitations in versions 1.0 through 1.2. Installer packages written for older versions of Windows Installer are fully compatible with version 2.0, but they gain no new capabilities; the packages must be recoded to use the new features. (For background on Windows Installer, see the sidebar "Windows Installer Overview".)

The major changes and improvements are as follows:

Support for signed packages. Windows Installer packages can now be digitally signed, allowing Windows Installer to detect application files that have been corrupted or tampered with prior to installation. Windows Server 2003 also supports software restriction policy in conjunction with signed packages, which allows administrators to prevent applications from being installed unless they meet specific criteria (such as bearing the signature of the company's IT department). This software restriction policy, however, only works with computers running Windows XP or later, and Windows Server 2003 Group Policy is required to set these policies. (For more information on digital signatures and public key technologies, see "Windows Public Key Infrastructure Extends Security" on page 3 of the Dec. 2001 Update.)

Improved Internet download. When a user with sufficient rights to install software launches an application installation by clicking a Web page link, Windows Installer now downloads only the MSI file and then, based on the installation options chosen by the user, only downloads the supporting CAB files needed to complete the installation. This reduces both the install time and impact on the network. Prior versions had to download all source files before beginning the installation.

64-bit support. Windows Installer 2.0 is the only version that can install 32-bit or 64-bit applications onto 64-bit versions of Windows.

Reduced need for original media. In many cases, users installing programs no longer have to supply original media while performing updates or patches. Windows Installer 1.x had to compare existing files with the original source media to see if they were unchanged and the correct version. Windows Installer 2.0 calculates file hashes and compares them with hash values stored in the MSI file. Unless specifically required by the package author, access to the original source is unnecessary, unless the file hashes do not match that of the originals. This feature makes patching or updating more efficient and more convenient.

Sandboxing of custom actions. Windows Installer 2.0 provides an isolated security partition (called a "sandbox") for performing "custom actions" during installation. Custom actions provide a way for an ISV to perform actions that Windows Installer doesn’t explicitly support. For example, an ISV authoring an application setup that includes installation of a Java applet could create its own custom action to register the Java code with the Java Package Manager, which keeps track of locally installed Java code so that it can be shared by other applets. The Windows Installer 2.0 sandbox gives custom actions limited, well- defined, and secure entry and exit points to the Windows Installer service. This keeps poorly written custom actions from accessing or damaging private data managed by the Windows Installer service, and prevents them from exploiting Windows Installer’s elevated privileges.

Improved event logging. Windows Installer 2.0 provides much more granular and detailed installation information to the Windows event logs than prior versions, making it easier to troubleshoot installation problems.

Finally, Windows Installer 2.0 includes support for installing "managed code" applications that run under the .NET Framework and for the new side-by-side component mechanism in Windows XP and Windows Server 2003.

.NET Framework Applications: Easier to Install?

The .NET Framework enables a new category of thick-client applications built using Visual Studio .NET (VS.NET) and the Windows Forms (WinForm) Class Libraries. (For details, see the Feb. 2002 Research Report, "The .NET Development Platform.")

Although the .NET Framework has no impact on the way traditional Win32 and COM applications install or run, .NET applications are somewhat different. During installation, .NET components no longer need to be registered in the system Registry to be properly located by other components, and the .NET Framework supports built-in component versioning facilities so that components never call versions of other components different from those they were expecting.

This capability has led to claims that installation of .NET components becomes a matter of merely copying the files to the appropriate places in the file system (XCOPY deployment). XCOPY deployment is possible for certain types of applications, including many ASP.NET applications. However, it is only practical for relatively simple WinForm-based .NET thick-client applications.

Overall, while the .NET Framework improves thick-client installation, the process is by no means automatic. Even though the component registration requirements go away, .NET applications face many of the other installation hurdles faced by earlier COM and Win32 applications:

• Applications that will use Group Policy to centrally manage configuration settings will still need to write and read per-user and per-machine configuration data from the Windows Registry, and applications that run as background services must use it to store startup information
• Desktop and menu shortcuts must be available so users can start the application
• Integration with the Windows "Add/Remove Programs" utility is necessary to provide local users (with administrative rights) a way to upgrade, repair, or uninstall the application
• The installation process needs sufficient rights to create or write to the target application directories, then set appropriate permissions on the installed files
• The installation process must perform other common installation tasks that make the process more robust, such as checking dependencies, handling exceptions, and making sure installation of all required components completed successfully (and if not, triggering a rollback to the preinstall state).

Furthermore, if the application uses the .NET Framework’s COM interoperability capabilities, it will still need to register its COM components.

However, for some types of .NET Framework WinForm applications that do not have any of the above requirements, XCOPY deployment will work fine. (See the Resources section at the end of this article for links to white papers that further explain when XCOPY is appropriate.) Furthermore, when XCOPY deployment is practical, then it may also be possible to use a technique called "no touch" deployment, in which a user clicks on a Web page link from a browser, which then downloads and runs a WinForm application. This scenario combines the benefits of Web applications’ self-service characteristics with the better interface and faster performance of thick-client applications.

One of the benefits of .NET applications is that they can use versioned components, even shared components, without encountering versioning problems similar to the DLL Hell woes so familiar to Windows users and developers. This built-in versioning support makes application installation or updating easier and much less likely to break working applications, since developers creating the application setup routines no longer need to worry about component registration or file naming conflicts caused by different versions of the same DLL.

Microsoft designed Windows Installer 2.0 with .NET Framework support in mind. It can be used to install .NET applications and to give them self-healing capabilities just like other applications installed with Windows Installer. It is also needed to install shared .NET assemblies into a storage location called the global assembly cache (GAC), and it takes care of updating reference counts so that shared .NET components are not deleted until all their dependent applications have been removed.

New Side-by-Side Component Support

Windows XP and Windows Server 2003 introduce a new feature—support for side-by-side "Win32 assemblies"—that allows new Win32 applications to use different versions of both private and shared Win32 components in a manner similar to the .NET Framework, relieving one of the last remaining causes of DLL Hell. However, because this feature is new to Windows XP, earlier Win32 applications cannot simply take advantage of it, unless rebuilt as Win32 assemblies.

Win32 assemblies are Win32 EXEs and DLLs that have an associated manifest (analogous to .NET assembly manifests), and that install into a special WinSxS ("side-by-side") system folder (analogous to the GAC) when shared by multiple applications. (For details on how this is done, see the sidebar "Shared Side-by-Side .NET and Win32 Components".)

With the new SxS support, an application that then calls one of these components does not risk failure if the assembly is updated to a new version to fix a bug or to provide new functions.

The new side-by-side component mechanism improves on the one introduced in Windows 2000, which was limited to supporting multiple versions of private components for a single application; globally shared Win32 components still used the old technology.

The new OSs come with SxS assemblies for the most common shared Win32 libraries. Windows XP comes with assemblies for Shell Common Controls (for common user interface controls), GDI Plus (for graphics routines), and the Visual C++ Runtime Library; Windows Server 2003 adds WinHTTP (for client applications to communicate with servers over HTTP) and Microsoft Isolation Automation (which enables scripts to call Win32 assemblies).

Microsoft may add additional shared Win32 assemblies in the future, and ISVs and other developers can also add new ones. However, Microsoft recommends they do this only if the component meets all of the following criteria:

• It exposes an API that will be used by many applications
• It will be shared by multiple applications which are not practical to rebuild as .NET applications
• It will run only on Windows XP or Windows Server 2003 (or later) systems (however, the underlying DLL is compatible with older Win32 OSs; it just reverts back to the older behavior)
• It runs in user-mode (i.e., it is not a kernel-level component or device driver).

Just as Windows Installer 2.0 is needed to properly install shared .NET assemblies into the GAC, it is also needed to install Win32 assemblies into the SxS directory.

Installation Nirvana Unlikely

As Microsoft, ISVs, and corporations migrate their client-side applications to use the .NET Framework, some installation problems will disappear, but the fact remains that thick-client applications are inherently more difficult to install and manage than their thin-client counterparts. Although nothing on Microsoft’s OS roadmap indicates that thick-client models will become as easy to manage as Web applications, the company does have plans for further application installation improvements in the next major release of the .NET Framework, which will accompany the version of Visual Studio that follows after Visual Studio 2003. Among other things, these improvements should make XCOPY and "no touch" deployment better by automatically performing tasks such as creating menu shortcuts and Add/Remove Program entries without having to use Windows Installer.

Even with the additional difficulty of distributing, installing, and managing them, thick clients have enough benefits that they will not be going away. Wireless networking is becoming increasingly popular, yet service coverage is rarely available in all the locations users need it, which mandates offline capabilities and thus thick-client applications.

Microsoft envisions that some existing Web applications will be rebuilt as thick-client applications that can consume Web services yet harness the local processing power of the device. However, Web services need years to mature before this practice is likely to become widespread.

Resources

For more information on Windows Installer 2.0, see msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp?frame=true.

For more information on SxS Win32 assembly support in Windows XP, see msdn.microsoft.com/library/en-us/dnwxp/html/sidexsidewinxp.asp.

For more information on installation of .NET Framework applications, see msdn.microsoft.com/netframework/techinfo/articles/smartclient.

For information on when to use Windows Installer versus XCOPY installations of .NET applications, see msdn.microsoft.com/library/en-us/dndotnet/html/xcopywininst.asp.

For a good white paper on authoring .NET installations, see www.installshield.com/downloads/isd/whitepapers/Authoring_.NET_Installations.pdf.