Lesson 4: Deployment Options

Once the Setup program is created and working properly, you are ready to deploy your application. This lesson discusses how to best get your application into the hands of users, and addresses some issues that you should consider when releasing your application.

Currently, the three most common means of deploying a Windows program are:

• On media such as a disk or CD-ROM.
• Over a network.
• Over the Internet.

After this lesson, you will be able to:

• Describe the advantages and disadvantages of deployment by media, network, and Web site.
• Describe the different setup requirements when deploying an ActiveX control as a product to other developers, as opposed to an ActiveX control serving as an auxiliary file for a container application deployed to users.
• Describe digital signing and explain its purpose.
• Understand how controls are licensed and the effects of licensing on the installation process.
• Design ActiveX controls intended for the World Wide Web.

Estimated lesson time: 20 minutes

Media-Based Deployment

Disks and CD-ROMs provide a cost-effective and convenient means of deployment. In their 3.5-inch form, disks also have the advantage of ubiquity, as nearly all users have access to a disk drive that can read the media.

Disk media are often used for the distribution of application upgrades, which can take the form of simple bug corrections or completely new versions. The upgrade package should include a Setup program that installs only the files that have been revised for the upgrade, making the installation as quick and convenient as possible.

Network-Based Deployment

Deployment via a network is the least expensive method, and is ideal if your application is intended to serve only a set of users within a company or group of companies. Such users are generally linked through a local area or wide area network, or both. Your disk images can be placed on a network share with access granted rights to all intended users, who can then simply run the Setup program over the network.

Deployment of applications with a site license usually involves two steps. First, the organization receives a single set of disks and copies the disk images and Setup program to a server. The users covered by the site license can then install the application over the network.

Web-Based Deployment

Deployment over the World Wide Web has become increasingly common in the last few years. Web-based deployment offers several compelling advantages:

• No packaging costs.
• No distribution costs other than the normal maintenance of a Web site.
• No reseller costs, as the software manufacturer can also fill the role of vendor.
• More efficient distribution to international markets, allowing customers in other countries to access a Web site written in their native languages and download only the application files localized for their languages.
• The opportunity for distribution of evaluation copies.

Time-trial evaluation software is a popular form of deployment over the Web. In this scheme, users download a working version of a program for free, and try it for a predetermined period. At the expiration of the evaluation period, the program politely refuses to run until users purchase a license. When obtained, the license typically arrives via e-mail in the form of a keyword, which the application recognizes as proof of a valid license. Once the keyword is entered into a licensing screen, users continue using the application as before, but now without time constraints.

The Web also serves as an excellent means of distributing application upgrades. The developer can place files in a common area, perhaps protected by a password known only to users. Registered users can be notified by e-mail that an upgrade has been posted, or the application itself can periodically check to determine if an upgrade exists. If an upgrade is available, users should always be informed and given the option of downloading the upgrade.

The potential disadvantages of Web-based deployment must also be considered:

• Inconvenience for users, who might be forced to download many megabytes of data over a low-speed connection.
• Customer base is restricted to users with Internet access.
• Care must be taken to make sure that site passwords are given only to licensed users.

Deploying ActiveX Controls

Lesson 3 of this chapter explained that ActiveX controls must be properly registered on a user's system, but there is a difference between deploying a product that is an ActiveX control and deploying a container application that merely uses an ActiveX control as an auxiliary component. The difference is particularly important when you have added licensing code to your ActiveX control.

This section discusses issues that you must consider when deploying an ActiveX control as a product, not as a dependency file for a main application. If your product is an ActiveX control (or suite of controls), your customers are most likely not users. Instead, they are likely developers who write applications or Web pages that use the controls, which in turn are distributed to users.

Control Dependencies

An ActiveX control using MFC must link dynamically to the MFC42.dll library file. The installation project for such a control must therefore include the DLL if you are deploying to sites where the file might not already be present. On the other hand, ATL can create ActiveX controls that are self-sufficient, requiring neither MFC nor the C run-time library. If you prefer your ATL control to be independent, do not include code that uses the C run-time library, and set the Release MinDependency configuration when compiling.

If you are deploying a group of ATL controls designed to work together, it's often more efficient to build them using the MinSize configuration instead of MinDependency. Choosing MinSize significantly reduces the size of the controls but makes them dependent on ATL.dll, a library file that Visual C++ installs in the System or System32 folder. Despite the 54-KB library file, the overall deployment size can be reduced when grouping two or more controls constructed using the Release MinSize configuration.

Digital Signing

Through their security settings, browsers can require downloadable software, such as ActiveX controls, to have a digital signature. A digital signature provides a way to verify that:

• The contents of the file are identical to when the file was digitally signed.
• The file comes from a responsible source.

A digital signature ensures that a file's contents have not been altered since the file was first made available for download. The signature verifies the source by identifying the legal entity that created the software. When you include a signature with an ActiveX control, you are the legal entity. The legal entity can be held responsible for any destruction caused by signed software when it is downloaded or run.

You provide a digital signature by purchasing a certificate from a certifying authority. A certifying authority is a company that validates your identity and issues you a certificate. The certificate contains your digital signature and is a verification of your credentials. In the event of any problems, the certifying authority becomes a witness to your identity. A private key is used to generate the digital signature, which can be validated using a public key that need not be kept secret.

Licensed ActiveX Controls

When deploying a licensed ActiveX control as a product, your installation program should handle licensing requirements automatically. Your developer-customers require the license to use your product in their own applications or on Web pages.

For example, when Control Wizard creates a project for a licensed ActiveX control, it generates a file named License.txt that must be placed in the same folder as the control itself. If you have written your ActiveX control to store license information in the system registry instead of in a file, your Setup program should register the required information during installation.

Regardless of how the license protection is implemented—whether by file, registry entry, or an alternative means—the license must be present on the developer's system or the control will not allow itself to be embedded. This protection is design-time license protection, which is verified when a developer attempts to insert the control onto a Visual Basic form or a dialog box template such as the one provided by the Visual C++ dialog box editor. If the license is not correctly installed, Visual C++ displays a message similar to the one shown in Figure 14.9, when a developer attempts to place the control on a dialog box.

Figure 14.9 Visual C++ error message when inserting an ActiveX control without a design-time license

Run-time license protection takes place after your developer-customer finishes the application or Web page that uses your ActiveX control. At run time, the container application passes a keyword to the control, providing proof that the license existed during development. After verifying the keyword, the control allows instantiation and runs normally. For this reason, the license is not required on the user's system when the application executes.

Making ActiveX Controls Internet-Friendly

An ActiveX control works best on the Internet when it appears quickly on a Web page, ready to interact with users. To this end, you should ensure that your ActiveX control:

• Is as small as possible.
• Can load its property data asynchronously.

Reducing the Size of an ActiveX Control

The first time a user views a Web page on which the control appears, the user's browser must download the control's file. The control should therefore be small to minimize download time. When coding an ActiveX control, take particular care to reduce the file size as much as possible.

An ActiveX control should be written to completely avoid using the C run-time library. This procedure helps decrease the control's executable size and also removes the MSVCRT.DLL file as a dependency, ensuring that the file is not downloaded along with the control. Some tips for writing an ActiveX control that does not require the C run-time library are as follows:

• Do not include C library calls in your code—use alternative services provided by the operating system. For example, substitute calls to strcpy() and strcat() with calls to the equivalent API functions lstrcpy() and lstrcat().
• Do not make member functions static, as static member functions require initialization by the run-time library.
• If you use ATL to create your control, make sure the compiler predefines _ATL_MIN_CRT. The ATL COM AppWizard sets the definition automatically; if you have created your project without the wizard, add the definition yourself. In the Project Settings dialog box, display the C++ tab and add _ATL_MIN_CRT to the Preprocessor Definitions text box.

Loading Data Asynchronously

By loading its data asynchronously, a control can become active even while the browser continues receiving downloaded properties in the background. This allows the control to become responsive as quickly as possible, even before all of its data arrives. If your ActiveX control requires large blocks of data, you should write the control so that it appears on a Web page ready to interact with a user using only a partial data set.

For example, a control that displays a video clip should not wait until the entire clip is downloaded. Instead, it should display the data already at hand while using a worker thread to continue buffering the rest of the file in the background as the browser receives it.

Deployment Checklist

This section provides a short checklist of miscellaneous items you should consider when deploying a Windows application:

• Make sure the application you are deploying has been built under its release configuration, not its debug configuration. Although Visual C++ by default optimizes the release version for speed, most programmers prefer to optimize for size. Often, this is especially the case when deploying ActiveX controls.
• Before including dependencies with your application, make sure they are legally distributable. Microsoft allows you to distribute both the MFC and the C run-time library modules (MFC42.dll and MSVCRT.dll) along with your Visual C++ application, but other vendors might impose restrictions on their products.
• Because users do not require licenses for ActiveX controls, do not include control license information in the installation package for container applications.
• Make sure your application's Help files are included in the installation package. It is not necessary to distribute the Windows Help Viewer WinHlp32.exe with the Help files, since every Windows system already has the Help Viewer installed. However, if your application uses HTML Help, you should include the HTMLHELP.dll file in your installation package.
• Test your Setup program thoroughly under different scenarios and on different operating systems. Ensure that it reacts correctly when encountering duplicate folder or file names, and under conditions of insufficient disk space and low memory.
• Apply the same tests to your uninstaller program, and ensure it correctly deletes files and cleans the registry.

Lesson Summary

Windows applications are distributed to users through one of three methods:

• On disks or CD-ROMs.
• As a Setup program running on a network.
• As a downloadable file over the Internet.

This lesson described these three methods and discussed some of their advantages and disadvantages. Deployment from a Web site offers the advantages of low cost and is an ideal medium for distributing evaluation copies to interested users.

It's important to understand the difference between deploying an ActiveX control as a product to other developers and as a dependency file to users. The difference is particularly important for licensed ActiveX controls. Licensed controls must include licensing information when distributed to developers so that they can embed the control in their own applications and Web pages. Users do not require licensing information, nor should it be made available to them.

An ActiveX control intended for Web distribution should be designed with the limitations of the Internet in mind. The control should be as small as possible to minimize download time, and should load large blocks of property data in the background while remaining responsive to users. Simultaneous loading of property data in the background is known as asynchronous loading.

As a final checklist for deployment, you should verify that:

• Your application has been built under its release configuration.
• Dependency files are legally distributable to users.
• All auxiliary files such as ActiveX controls, Help files, and font files are included.
• Your Setup and uninstaller programs have been tested and work as expected.