Deploying ADO | Ado Examples and Best Practices

Team-Fly

Deploying ADO on the target system is one of the most complex and troublesome issues facing any ADO (or COM) developer today. While tasks such as analysis, design, and testing have become regular steps in most development efforts, application deployment is often an overlooked step in the development process.

Deploying a COM solution generally involves many installation tasks, including the following:

Distributing files
Creating Registry entries
Creating desktop icons
Updating software components on client machines

Microsoft's Visual Basic Package and Deployment Wizard, and many third party deployment tools, are capable of automating the deployment process. However, many of these tools don't take advantage of the latest technologies to accomplish a conceptually simple task—installing the software!

For example, these tools often require that the author create installation scripts to set predefined paths and installation options. Developing installation scripts becomes increasingly difficult as solutions become more complicated and interdependent. Writing an installation script that copies three files is simple, but writing a script for a solution that shares a file with other applications is more difficult. Add uninstall logic, and these scripts become unmanageable.

Installation programs face an additional problem: How do you create an installation procedure that accounts for all of the differences between client machines? From what applications are installed to what operating system features are active, accounting for all of the variations that an installation procedure might encounter is a difficult, seemingly insurmountable, task. When scripts are created for installation procedures, authors need to anticipate the environment before the installation occurs. In other words, you have to know what the target system looks like, what's installed, what's not installed, and how many resources are available. Increasing the amount of information shared between the installer and the operating system can reduce the difficulty of this task.

Creating installation scripts is a difficult task that is required by most installer tools. Visual Studio Installer eliminates this step and other inherent difficulties associated with creating robust, efficient installation programs. When used in conjunction with the Windows Installer technology, Visual Studio Installer seems to be the best choice for creating fast, manageable, robust installation applications for Visual Studio-based solutions.

The Visual Studio and Windows Installers

To help solve some of the problems associated with installation programs, Microsoft has introduced the Windows Installer as a means of deploying applications. Windows Installer technology is a part of Microsoft Windows 2000 and is also available for Microsoft Windows 95, Windows 98, and Windows NT 4.0 operating systems. You'll see it install automatically when you install Office 2000 or any application that uses the Visual Studio Installer.

The Microsoft Windows Installer is not script-based like most other installation program development tools. Instead, the Windows Installer serves as a host for data-driven installation packages. Windows Installer uses "bundles" of data, called packages, to contain information about what components are required by a solution. The Windows Installer utilizes the information in a package to determine:

How components are installed on a machine
Which Registry settings need to be created or modified
The default location of files
Whether or not desktop icons need to be created
Other installation-time information

All this is accomplished without the developer writing a single line of installation code. The highly interactive data-driven model represents a great advance over the traditional script-based approach. Data-driven installations avoid many of the complexities associated with script-based installers and reduce the workload of developers and operational support workers.

I saw this technology demonstrated at VBits in the fall of '99, and it was impressive. After a Visual Basic application was installed with the Visual Studio Installer, the speaker deleted some of the MDAC files and restarted the application. The system (Windows 98 in this case) went out, reinstalled those files and repaired the damage. Cool.

You can get the Visual Studio Installer from the Web (http://msdn.Microsoft.com/vstudio) or from the Visual Studio Plus Pack or Windows 2000 Readiness Kit (which is in the Visual Studio Plus Pack).

Team-Fly