Installation and Update Management: Roadmap
Installation and Update Management: Roadmap
Introduction
The Windows Vista® investments in high-level installation and update management technology provide developers with great power and flexibility in creating tools for application management.
To support improved installation and upgrade experience in Windows Vista, Microsoft has invested in two robust and complementary installation mechanisms: Windows Installer and ClickOnce, a Web-based deployment technology. Each installer has its own architecture and installation model. Developers can choose between the traditional Windows Installer and the Web-based ClickOnce.
In general, use Windows Installer when an installation:
Adds a shared application for multiple users
Alters system configuration through registry modification or by changing critical system directories (such as the Startup group)
Needs to add or change drivers
ClickOnce technology is useful for Web-centric environments where the installed application meets one or more of the following requirements:
Needs only limited user rights
Can run in a private area
Requires frequent updating
Does not need shared system components
Runs locally without actually installing any software
The following table outlines the most important differences between Windows Installer and ClickOnce.
Issue |
Windows Installer |
ClickOnce |
|---|---|---|
Requires .NET Framework 2.0 |
No |
Yes (can be provided by a bootstrapping application) |
Creates a local copy of the application |
Optional (can be run from network) |
Optional (can be run in online-only mode) |
Runs in a private area |
No |
Yes |
Application installation location |
Any folder |
ClickOnce application cache |
Installs for multiple users |
Yes |
No |
Installs shared files |
Yes |
No |
Installs drivers |
Yes (with the Driver Install frameworks) |
No |
Installs to the global assembly cache |
Yes |
No |
Modifies the Startup group |
Yes |
No |
Modifies the Favorites menu |
Yes |
No |
Registers file types |
Yes |
No |
Accesses the registry |
Yes |
No (except for HKLM with Full Trust permissions) |
Initiates binary patching of files |
Yes |
n/a |
Installs assemblies on demand |
Optional (features containing assemblies can be advertised) |
Yes |
In addition to Windows Installer and ClickOnce, Windows Vista gives developers direct access to an enhanced download and remote update functionality through the Background Intelligent Transfer Service (BITS). BITS allows more efficient data transfer during custom update operations, handles transmission interruptions, and provides users with greater control.
ClickOnce Deployment Strategy
Any Microsoft® .NET Framework version 3.0 Windows Forms or console application that is built and published using ClickOnce is referred to as a ClickOnce application. This means that ClickOnce can be used on earlier versions of Windows that have been upgraded to support the .NET Framework Runtime Components (version 3.0). Windows Vista provides native .NET Framework 3.0 support and does not require an upgrade.
ClickOnce applications can isolate and improve security with a limited set of permissions based on the security zone from which the application is installed. Further stability is provided by having all ClickOnce applications run out of a family of hidden directories, the ClickOnce application cache, under the Local Settings directory of the current user's Documents and Settings folder, whether the application is installed locally or hosted online.
Note
The ClickOnce application cache is part of Microsoft's ongoing investment in creating a unified application store. It provides a single location for application storage, takes the burden away form users of managing the physical installation of an application, provides application isolation, and eliminates the need for restarts.
Create a ClickOnce deployment by constructing two configuration files (the application and deployment manifests) and a deployment Web site, file share, or distributable media.
Developers can perform the construction manually, through ClickOnce stand-alone tools (Mage.exe and MageUi.exe), or through the Visual Studio® 2005 wizards. For more information on creating manifests, see the Manifest Generation and Editing Tool (Mage.exe) and Manifest Generation and Editing Tool–Graphical Client (MageUI.exe) sections of the Windows Software Development Kit (SDK) documentation and the Visual Studio 2005 documentation.
The application manifest describes the application itself, including the assemblies, dependencies, and files that make up the application, as well as the required permissions and the location where updates will be available. The deployment manifest describes how the application is deployed, including the location of the application manifest and files and the version of the application that clients run.
With the manifests, the ClickOnce API (found under the System.Deployment namespace), command line and graphics utilities, software developers are able to:
Specify deployment and update strategies (specified in manifests)
Define a security configuration
Set up deployment on a Web site, network share, or removable media
Configure proper prerequisite and security settings
Control access to local and remote data
Choosing a ClickOnce Deployment Strategy
The installation can require Internet access or proceed without Internet access. Depending on the choice, a ClickOnce application can be installed to run locally even when the computer is offline, or run in an online-only mode without permanently installing anything on the user's computer.
All deployment strategies are specified in a ClickOnce installation deployment manifest. There are different strategies for deploying an application using ClickOnce: Installing from the Web or a Network Share, Installing from Media, and Launching from the Web or a Network Share.
Installing from the Web or a Network Share
Installing from the Web or a network share is the default deployment strategy. This scenario requires access to a ClickOnce deployment available on a Web server or a network file share.
When invoked through Microsoft Internet Explorer® by either clicking an icon representing a deployment manifest on a Web page or by double-clicking a manifest file icon found on a file share:
The ClickOnce application is downloaded, installed, and then launched on the local system.
Items are added to the Start menu and the Add/Remove Programs group in Control Panel.
This strategy works best for applications that are deployed to users who have access to a local area network or a high-speed Internet connection.
Installing from Media
This strategy uses a deployment on a removable medium, such as a CD-ROM, DVD, or USB flash drives. When invoked through Windows Explorer (by double-clicking a manifest file icon found on the removable storage medium):
The ClickOnce application is copied to the local disk, installed, and then launched.
Items are added to the Start menu and the Add/Remove Programs group in Control Panel.
This strategy works best for applications that are deployed to users without persistent network connectivity or with low-bandwidth connections. Although no network connection is required for installation, network connectivity is necessary for getting updates.
Launching from the Web or a Network Share
Like Installing from the Web or a network share, this scenario requires access to a ClickOnce deployment available on a Web server or a network file share. However, unlike Installing from the Web or a Network Share scenario, the application is not actually installed on the user's system.
In this scenario, when a user starts a ClickOnce deployment, the application is launched, but not permanently installed. So when the user closes the application, it is no longer available on the local computer. No items are added to the Start menu or the Add/Remove Programs group in Control Panel.
This strategy works best for applications that are used infrequently: for example, an employee-benefits tool that typically is run only once a year.
Determining an Update Policy
Automatic update support is built into ClickOnce applications. If enabled—and if access to an update site is present—a ClickOnce application queries the deployment site's manifests to determine whether an update is available.
If an application cannot connect to the network or a connection is not present, the application runs without checking for updates, regardless of the update strategy.
If updates are available, the new version of the application is downloaded, replacing the older version. For efficiency, only those files that have changed are downloaded.
Developers need to determine whether their ClickOnce application will:
Update on a background thread.
This is the default update strategy. At regular intervals, a ClickOnce application spawns a background process after start up and tries to locate and read the deployment manifest file. If an update is found, the next time the user runs the application, the user will be prompted to update.
This strategy works best for low-bandwidth network connections or for larger applications that might require lengthy downloads. Developers can set the frequency that applications check for updates.
Update on application start up.
Each time it is launched, the ClickOnce application tries to locate and read the deployment manifest file. If an update is available, the user is prompted to download the update; otherwise, the existing version of the application is launched.
This strategy works best for high-bandwidth network connections. Over low-bandwidth connections the delay in starting the application might be unacceptably long.
Check for updates by providing a user interface.
The application provides the user with a User Interface that enables the user to choose when or how often the application will check for updates. For example, developers can provide a "Check for Updates Now" menu item or an "Update Settings" dialog box with choices for different update intervals.
The ClickOnce deployment APIs, found in the .NET Framework 3.0 System.Deployment namespace, provide an environment for developing user interfaces for updates.
This strategy works best when different update strategies are required for different users.
Block from updating.
It is possible to prevent applications from checking for updates. This can be appropriate for a simple application that will never be updated. This mode also takes advantage of the ease of installation provided by a ClickOnce deployment.
Use deployment security.
The following table outlines the assignment of each ClickOnce application security zone on the basis of deployment location.
Deployment location |
Security zone |
|---|---|
Launch from Web |
Internet zone |
Install from Web |
Internet zone |
Install from network file share |
Internet zone |
Install from CD-ROM |
n/a |
Not supporting networked updates |
Full trust |
Supporting networked updates |
Internet zone |
Software developers must ensure that an application will run with the appropriate permissions.
Note
Visual Studio can emulate any given security zone, so developers can run and debug in the expected user environment.
If a ClickOnce application requires elevated rights to interact with a program such as Microsoft Excel® or Microsoft Word, this requirement can be specified in the application manifest. During installation, the system prompts the user to grant permission. If the user accepts, the application installs; if not, the installation is stopped.
In addition to permission-based security, ClickOnce supports digital signatures to identify the author and ensure that the contents of an installation package have not been tampered with. This minimizes the threat of a malicious third-party misrepresenting a virus or presenting other harmful applications as legitimate. ClickOnce developers should use Authenticode®, Microsoft's industry-standard cryptography, to sign application code with digital certificates that verify the authenticity of the application's publisher.
Setting Up a Deployment
After the application has been deployed and the application manifest is written, the actual ClickOnce installation site needs to be created. Developers must copy the deployment manifest to a location on a Web server, network file share, or medium (such as a CD). The application manifest and all the application files are also copied to an accessible location, specified in the deployment manifest. The location of the application files do not need to be the same as that of the deployment manifest.
After the application is deployed to a public location, users can download and install the application by clicking an icon representing the deployment manifest file, found either on a Web page or in a folder.
A deployment manifest also can contain an update location (a Web page or network file share) where the application will check for updated versions of the application and specify an update strategy.
When an update needs to be made available:
Generate new application manifest and application files then copy them to an accessible location, usually to a sibling folder of the original application folder or to the update location.
If no update location is specified by default, the deployment manifest is modified to point to the location of the new version of the application.
Note
The Publish Wizard in Visual Studio can copy files and update manifests for installation, or update the manifests automatically.
In most cases, users will be presented with a simple dialog box asking them to confirm installation, and the installation proceeds. Then the application launches without further intervention. In cases where the application requires elevated rights, the dialog box also asks users to grant permission before the installation can continue.
The application is added to the Start menu and to the Add/Remove Programs group in Control Panel. Unlike other deployment technologies, nothing is added to the Program Files folder, the registry, or the desktop, and no administrative rights are required for installation.
Customization
Although not as flexible as Windows Installer, ClickOnce provides some ability to customize the operation of an installer. Areas of possible customization include:
Application and deployment manifests can be edited with the ClickOnce Wizard, the Manifest Generation and Editing Tool (Mage.exe or MageUI.exe), or manually (to specify custom behavior). This is the most common and basic method of customizing a ClickOnce installer and application update behavior. For a full description of these manifest schemas, see "ClickOnce Reference" in the Windows SDK.
As an alternative to specifying update behavior in the deployment manifest, developers can use the types in the System.Deployment.Application namespace to programmatically specify upgrade behavior of a ClickOnce application.
Custom application and user preferences can be stored on the client using the LocalFileSettingsProvider default class. Developers can create a custom settings provider to persist this information in some other manner, for example through a Web service. For more information, see "Application Settings Architecture" in the Windows SDK.
It is also possible to modify the bootstrapper portion of the Installer to perform custom actions during the initial installation. For example, one common custom operation is to verify prerequisites and install them if they are missing, such as the .NET Framework. (The ClickOnce Wizard can accomplish this for common prerequisites). For more information, see "Creating a Single Setup Project to Install a .NET Framework Application and Dotnetfx.exe" in the Windows SDK and "Use the Visual Studio 2005 Bootstrapper to Kick-Start Your Installation" in the MSDN Magazine, online.
Windows Installer Deployment Strategy
Windows Installer builds on the robust and familiar installation support well-known to developers and users alike. Improvements in Windows Installer focus on supporting improved security and application reliability models and on allowing greater customization of the installer interface.
For more information, see "Windows Installer" in the Windows SDK.
Integration with Windows Vista Security
Windows Installer installations often need to modify critical system resources that require administrative rights, for example the Local Machine hive of the Registry (HKLM) or the Windows System directory. Previous versions of Windows lacked an easy-to-use mechanism for short-term user rights elevation, so many users always logged on under accounts actively running with administrative rights, which increased the damage that an application with malicious intent could cause. Windows Installer is now fully integrated with the Windows® User Account Control (UAC), Mandatory Integrity Control (MIC), and Windows Resource Protection (WRP) technologies.
The Windows Installer interface automatically provides software developers support so they can provide users with temporary rights elevation on-the-fly when an installation modifies critical system resources. If developers specify the modification of a critical resource when constructing a Windows Installer installation, they can be guaranteed that when the installer is run under Windows Vista, users will be presented with the option to temporarily elevate their permissions for the installation. Therefore, users do not need to be logged on as Administrator to install an application.
The Windows Installer APIs also provide tools for customizing interaction with the security system.
Integration with the Restart Manager
The Windows Installer makes use of the Restart Manager to enhance its existing restart handling to avoid forcing users to restart their computers. Instead, computer-required services and user-mode applications are restarted as needed, and only after receiving the user's consent. If a system restart is required, it is imposed on the user, but will be scheduled. This support is largely transparent to developers, who need only specify which resources (such as files or registry keys) must be modified. Windows Installer then creates an installer that uses the Restart Manager to handle interactions with other resource managers, running applications, and open files. That installer can dynamically release and acquire services or applications as needed.
Application Reliability and Manageability Features
Software developers can use several new features to improve installer and application reliability. These features include:
Support to enable "logging on" programmatically from within Windows Installer. Previous releases only enabled "logging on" through command line and policy settings.
Additional properties in the Windows Installer Provider that describe more fully the new functionality of the Windows Installer and installations.
Miscellaneous Developer Features
Changes throughout the Windows Installer platform have been made in version 4 to increase functionality, performance, and compatibility with Windows Vista.
These changes include:
Numerous additions to the Windows Installer API, including the MsiGetPatchFileList function.
Support for internationalization through inclusion of Multilingual User Interface (MUI) resources.
Patchwiz version 4.0, a simpler, faster patch creation tool that supports logging and environment variables.
For more information, see "What's New in Windows Installer Version 4.0" in the Windows SDK.