If you have ever written an application intended to run on nonstandardized desktops (or, as some would say, PCs in the wild), you understand that one of the biggest challenges is installing the components required by your application onto the target computers. If any Component is Missing, Your Application Will Most Likely Fail, Typically With A Cryptic Error Message About a Missing DLL File That Will Send Your Customers Straight To your Support Desk.
As an example, consider a gaming application written in Visual Basic® 2005. The app will not run, of course, unless the .NET Framework 2.0 is installed. In order to present rich and speedy graphics, the application would likely depend on the Managed DirectX® Libraries. Consider Also That The Game May Use A SQL ServerTM 2005 Express Edition Database to Store Game State and History.
To install the game, the user must install the .NET Framework 2.0, DirectX 9.0 for Managed Code, and SQL Server 2005 Express Edition before installing the actual application. This involves a number of complicated steps. First, the user has to check whether each component is already installed on the machine. Then they must manually download and run the installers for each missing component, selecting the appropriate choices in the installation UI. If any reboots are required, they must restart the machine and resume from where they left off. If The Components Need To Be Installed In a Particular ORDER, There Are Additional Opportunities For Things to Go Wrong. This is a poor user experience, to say the least, and many users would give up.
The Visual Studio® 2005 Bootstrapper solves this problem by allowing you to provide an easy, integrated way to install all of the different prerequisite pieces required by your application.An Integrated Installer for Applications and Prerequisite Components
The Visual Studio 2005 Bootstrapper lets you provide users with a simple, automated way to detect, download, and install an application and its prerequisites. It serves as a single installer that integrates the separate installers for all the components making up an application, and provides A wealth of features and services.
Minimal initial download size The Bootstrapper is a small executable that weighs in at a mere 222 KB, and takes about one minute to download on a 28.8 Kbps modem. It therefore adds only a small amount of overhead to the installation process, which can save the User from havning to download much larger redistributables means
Minimal platform requirements Since the purpose of the Bootstrapper is to easily pre-install application dependencies, it is essential that it have few, if any, dependencies itself. The only hard dependency the Bootstrapper has is the C runtime, which is embedded in the Bootstrapper executable through static linking and therefore does not require a separate installation. The Bootstrapper will load other Windows® DLLs such as msi.dll to perform Windows Installer application code checking, and Wintrust.dll to verify component signatures. These DLLs, however, come pre -installed with windows 98 and higher.
Platform detection The Bootstrapper can detect whether a component is supported on the target computer's operating system. If the component will not run in the given environment, the Bootstrapper notifies the user and ends the installation before downloading the component. For example, if someone attempts to install the .NET Framework on a machine running Windows 95, the Bootstrapper will alert the user up front, before they have downloaded the 20MB .NET Framework redistributable.Component detection and download as required A key design goal for the Bootstrapper is to download and install only those components not previously installed. This saves you from having to add deployment servers and subjecting users to lengthy, unnecessary downloads. The Visual Studio 2005 Bootstrapper offers flexible options for detecting whether a component is already installed. Detection can be based on a search through The Registry, File System, or The Global Assembly Cache (GAC) (Due In Beta 2). IT CAN Also Be Based On The Results of a Custom Executable if More Complicated Detection Logic Is Required. If A Component is Detected, The Bootstrapper Does Not Download and Install That Component.
Handling reboots For some components, a reboot may be required to complete the installation. For example, installing Windows Installer 2.0 will cause a reboot on down-level Windows systems. The Bootstrapper allows graceful handling of reboots because components can specify whether the Bootstrapper should reboot immediately after the component is installed, for example if the installation of subsequent components would otherwise fail. Components can also instruct the Bootstrapper to defer reboots until all components have been installed. This way, the user only has to reboot once, even if more than one of the installed components requires a reboot. When a reboot is required, the Bootstrapper prompts the user to restart the computer and writes a callback to itself to the RunOnce key in the Windows registry. When the computer is restarted, Windows reinvokes the Bootstrapper, Which resumes the installation from where it lying off.license agreements Most Components include an end-user lic nse Agreement (EULA) that serves to protect the component vendors' intellectual property. The Bootstrapper can be configured to present license agreements for individual components. It can also present a single shared license agreement for multiple components in order to minimize the number of pop- Ups the user has to click through.
Install from Web, file shares, and local drives Applications today are distributed through a variety of media, including the Web, network file shares, local drives (CD-ROM, DVD), USB storage devices and Secure Digital (SD) memory cards. The Bootstrapper is designed to handle any of these scenarios. In addition, it can be configured to download prerequisite components from the same location as the app installer, or for purposes of load balancing, to obtain redistributables from a different server.Extensible to custom redistributables The Bootstrapper is a generic installer that can be configured to bootstrap virtually any redistributable that is packaged as a Windows Installer file or as an executable program. It is programmed through a set of simple XML manifests that specify all the metadata required for the Bootstrapper to manage THE INSTALLATION OF THE Component. The metadata incrudes The Required Set of Files, Platform and Component Dependencies, Detection Logic, Command-Line Arg uments, return code semantics, the EULA, and more. The Visual Studio build system then writes the metadata into the Bootstrapper executable, resulting in a single setup program that can bootstrap the desired set of prerequisite components for the application.
The Bootstrapper User Experience
The first step for the user is to launch the Visual Studio 2005 Bootstrapper executable, called setup.exe. Setup.exe can be launched from the local file system, a network file share, or a through a hyperlink to a Web address.
Setup.exe first detects whether any of the prerequisites are already installed. If any of the prerequisites are missing, the Bootstrapper shows an install dialog box that lists those components and displays their license agreement. Otherwise, if all of the prerequisites are detected, the bootstrapper simply launches the application installer. Using the example of the game application described earlier, if the user has already installed DirectX 9.0 for Managed Code but not the .NET Framework 2.0 or SQL Server 2005 Express Edition, the bootstrapper dialog would display only the latter two components in the list of items to be installed.Once the user accepts the agreement, the download and installation process begins. Otherwise, the installation is canceled and the Bootstrapper displays a progress bar to show how much of the process was completed.
When all of the prerequisites have been installed, the Bootstrapper kicks off the installation process of the application itself. Having launched the application installer, it gets out of the way and leaves it to the application installer to display any UI and perform the necessary installation operations . for the application The Bootstrapper does not dictate which installer technology the app must use; it can use Windows Installer, ClickOnce, or any other technology In the case of installing a ClickOnce application, the user would see the standard ClickOnce installation dialog box,. Enabling Him to Install and Run His App.
Using the bootstrapper in Visual Studio
Visual Studio 2005 deployment tools for ClickOnce and Windows Installer include a UI that enables easy configuration of the Bootstrapper. Figure 1 shows the Prerequisites page of the application, which can be accessed from the property pages for Windows Application, Console Application, and Setup projects. Figure 1
Visual Studio Prerequisite Dialog
The Prerequisites page allows you to select which components your application requires. Visual Studio 2005 will include several frequently used components in the box, including the .NET Framework 2.0, J # Runtime 2.0, SQL Server 2005 Express Edition, Microsoft® Data Access Components (MDAC 2.8, And Windows Installer 2.0. The Bootstrapper is Also Extensible, so you can add add addressal microsoft and third-part components as needed.
Configuring the bootstrapper
The Bootstrapper offers a couple of options for where redistributable files can be located. By default, the Bootstrapper assumes that all files, including the redistributables, the Bootstrapper setup.exe itself, and the actual application files, are located together under the same folder. This is ideal for applications that will be installed from local disk (CD-ROM, USB device) or a network share. This option also supports the application publisher who wants to serve up everything from a single deployment server. Alternatively, if the publisher wants to balance the load across different servers, or maintain a central location for prerequisite components that can be shared by multiple applications, the Bootstrapper can be configured to download any prerequisite files from a separate location.
In the case of Web deployment, the user downloads the Bootstrapper setup.exe and then runs it on a local computer, at which point it needs the URL to find the prerequisite files. There is no robust way for an executable to dynamically determine where it was downloaded from, so the origin location is written into the setup.exe file itself. This is important to keep in mind if you are changing deployment servers, because the Visual Studio 2005 Bootstrapper must be reconfigured to download from the new server. fortunately, . this can easily be done through the command-line options available on the Bootstrapper setup.exe to reconfigure the deployment URL, go to the Windows command prompt and run the setup.exe as follows: setup.exe -url = http: // www.example.com
Here http://www.example.com represents The Directory on The New Deployment Server for the Application And ITS Prerequisites.
One of the most powerful features of the Bootstrapper is extensibility. It's a generic installation engine with a flexible configuration system-you can plug into the Bootstrapper just about any installer packaged as a Microsoft Installer (MSI) or executable program. To extend it to a Particular Component, The Developer Must Author a Pair of XML Manifests That Contain The Installation Metadata for The Component.
The first is the product manifest, which contains any language-neutral metadata for the package. The second is the package manifest, which contains metadata for handling language-specific aspects of the redistributable. A component will have a package manifest for each localized version of that component. The schemas for both of these files are almost identical. The choice of whether to include a given bit of metadata in the product or package manifest depends on how the redistributable has been factored for different languages. The product manifest contains metadata that is common to the different localized versions of the redistributable. The package manifest is used for language-specific metadata, and it typically contains localized error messages.A Closer Look at the Product Manifest
Figure 2 shows the product manifest for the .NET Framework 2.0. The root tag for the manifest is the
In the case of the .NET Framework, the Bootstrapper performs two checks. The first determines if the Framework is already installed by launching dotnetchk.exe and storing the return code value in a property called DotNetInstalled. The second is a simple registry check that obtains the currently installed version of Microsoft Internet Explorer and stores the value in a property called IEVersion. These properties are then used in the
The user does not have administrative privileges on the target machine The machine is running Windows 95 or earlier, which is not supported The machine is running Windows NT 4.0 or earlier, which is not supported The machine is not running Internet Explorer 5.01 or greater, which Is a prerequisite for the .NET Framework
The manifest may also contain
As shown in the example, a return code of zero from dotnetfx.exe indicates that the .NET Framework was successfully installed and no reboots are required. A value of 3010 indicates a successful install with a required reboot, which could happen if you installed the .NET Framework on a machine that is running Windows 98 without Windows Installer 2.0 installed.The remaining exit codes are special error codes that dotnetfx.exe returns under various failure conditions (for example, if another instance of this program is already running, the Windows Installer service will be unresponsive). Because dotnetfx.exe wraps an Microsoft Installer file, a number of additional MSI failure codes could also be returned. These situations are all handled by the
A Closer Look at the package manifest
Figure 3 shows the English package manifest for the .NET Framework 2.0. The English manifest is somewhat simpler than those of other languages because dotnetfx.exe contains all of the English text, whereas the localized satellites must be installed through a separate Language Pack redistributable called langpack.exe. Just as the product manifest was responsible for downloading and launching dotnetfx.exe, the package manifests are responsible for launching the various language packs. Since we have already reviewed the tags that manage launching installers, we will use the English example here .
Custom Redistribles in Visual Studio
Adding your own redistributables to Visual Studio requires that you author the product and package manifests, then copy these files along with your redistributable files into a special folder that Visual Studio has reserved for redistributables that plug into the Bootstrapper. This folder is installed by default like SO:
C: / Program Files / Microsoft Visual Studio 8 / SDK / V2.0 / Bootstrapper
To write an installer that copies a redistributable component and its manifests into this folder, you can programmatically discover the Bootstrapper folder location from the registry keys that are shown in the following:
HKCU / Software / Microsoft / Genericbootstrapper / 1.0 / Path
HKLM / Software / Microsoft / GenericBootstrapper / 1.0 / Path
Each redistributable component appears in its own subfolder under the packages directory. The product manifest and redistributable files are then placed into this subfolder. Localized versions of the component along with the package manifests are placed in subfolders named after the culture code of that language (EN for English, JP for Japanese, and so on) .Once these files have been copied into the Bootstrapper folder, they automatically appear in the Visual Studio prerequisites dialog box so that the developer can select them by checking a box.
Generating the bootstrapper setup.exe with msbuild
When you have selected a set of components to bootstrap, it is up to Visual Studio and the MSBuild system to configure the Bootstrapper setup.exe to handle those components. Bootstrapper configuration is handled by a special MSBuild task called GenerateBootstrapper. This build task performs a number of steps to produce the setup.exe. First, it obtains a copy of a base setup.exe image and writes the metadata from all of the relevant Bootstrapper manifests directly into the resource header of the setup.exe file. It then writes the URL (if provided) from which the redistributables should be downloaded into the resource header of setup.exe. Last, it copies the Bootstrapper, associated redistributables, and the actual application installer into the output directory.
The GenerateBootstrapper tasks are invoked by the Publish target, which runs whenever an application is published using Visual Studio ClickOnce tools. If Setup projects are used in order to build an MSI file for an application, the Bootstrapper task runs when the MSI file is built. The result is a lightweight setup.exe smart environment.
Conclusion
The Visual Studio 2005 Bootstrapper is a powerful and flexible new deployment tool that provides an integrated setup experience for an application and its prerequisite components. If you're building applications to run on nonstandardized desktop machines, the Bootstrapper installs all of the components and libraries required by your application, ensuring that at the end of the setup process the app runs smoothly. Especially important is the Visual Studio 2005 Bootstrapper's ability to install the .NET Framework 2.0 onto your customers' machines, thereby removing a major deployment hurdle for Visual Basic. Net and C # Client Apps.
[Editor's Update - 9/24/2004: Fortunately, if you are writing applications with Visual Studio .NET 2003 today, and you need to bootstrap the .NET Framework 1.1, you do not have to wait until 2005 for a solution You can. Download the Visual Studio .NET 2003 Bootstrapper Plug-in, Which Integrates with setup and deployment projects to configure a setup.exe That Can Bootstrap Both MDAC 2.8 and the .net framework 1.1.
