Deployment Changes in Visual Basic .NET
Summary: This article provides an introduction to deployment for Microsoft Visual Basic 6.0 programmers making the transition to Visual Basic .NET. (7 printed pages)
This article is divided into the following sections:
You have built your first application using Visual Basic .NET, and now it is time to distribute it. You search for the Package and Deployment Wizard, but you cannot find it—so how are you going to distribute your application? Do not worry, because Visual Studio .NET includes everything you need. The process is different than what you may be used to with Visual Basic 6.0, but ultimately it is easier and much more powerful.
This article will introduce you to the concepts and processes for distributing applications and components created with Visual Basic .NET. There are also pointers to topics in the Visual Studio .NET documentation that will help you to accomplish numerous tasks. In addition, it will provide some tips that will help you avoid potential problems.
In Visual Basic 6.0, you typically used the Package and Deployment Wizard to create a script-based Setup.msi for your application. The Package and Deployment Wizard could be run as a stand-alone tool or as an add-in to Visual Basic; it could only be used with Visual Basic projects.
In Visual Basic .NET, you use a deployment project to create an installer (.msi file) for your application. Unlike the script-based setups, the installer uses Microsoft Windows Installer technology to manage the installation for you. For example, the installer automatically rolls back installation when something goes wrong. For more information on Windows Installer technology, see Introduction to Microsoft Windows Installer.
Whereas the Package and Deployment Wizard was a separate tool, deployment projects are an actual project type in Visual Studio. A single deployment project can be used for multiple pieces of an application created in different programming languages, or multiple deployment projects can be used within a single solution. Deployment projects are added to a solution just like any other project type, by means of the New Project or Add Project commands on the File menu. For more information, see Creating or Adding Deployment Projects.
Tip When distributing components within a solution, you can use Merge Module projects for each component. Merge modules are like a snapshot of a specific version of your component, insuring that the correct version is always installed. For more information on merge modules, see Introduction to Merge Modules.
Visual Studio also includes a Setup Wizard that will step you through creating a deployment project. Even if you generally do not like wizards, it can give you a good idea of what the resulting deployment project looks like. The wizard is launched by means of the New Project or Add Project commands on the File menu.
In Visual Basic 6.0, deployment was an afterthought: After you were through building and debugging your application, you would run the Package and Deployment Wizard and distribute the application. Often the application (which ran fine on your development computer) would not run properly on another computer.
In Visual Basic .NET, deployment is an intrinsic part of the development process. Rather than waiting until the end of the process, you should add a deployment project to your solution at the beginning, so that any changes to your project are automatically reflected in the deployment project. You can build the deployment project and test the installation at any point during development; because of the uninstall capabilities of Windows Installer, you can easily remove your application after testing.
Steps in the Deployment Process
The following steps describe a typical deployment process. Not all steps are necessary in all cases, and there are additional optional steps as well.
- Add a deployment project to your solution.
- Associate the deployment project with your application project.
- Specify where files will be installed.
- If you need to add files that are not compiled into your project (such as Help files), you can add them.
- If your application uses Microsoft Data Access Components (MDAC) version 2.6 or later, add a launch condition to check for it.
- Build the deployment project.
- Run the setup executable to install your application files on another computer.
The first step in deployment is to add one or more deployment projects to your solution. If your solution includes component projects, you will want to add a Merge Module deployment project for each component as well. For more information on choosing a deployment project type, see Installer vs. Merge Module Recommendations.
Tip When adding a deployment project, you should give it a meaningful name; otherwise, it will use a default name such as Setup1. The project name is used as the default product name for the application in the dialog boxes displayed during installation. Therefore, using the application name as a project name saves you from having to set other name properties later.
When you add a deployment project to your solution, the File System Editor is automatically opened. The File System Editor is a representation of the file system on a target computer; you use it to specify where files will be installed. In most cases, you will want to place application files in the Application Folder, or in subfolders that you create beneath the Application Folder. When installed on a target computer, files from the Application Folder will be located in the Program Files\Manufacturer\ProductName folder, where Manufacturer is the Company name that you used when you installed Visual Studio, and ProductName is the name that you used for the deployment project.
Tip You can override the default names by setting the Manufacturer and ProductName properties for the deployment project. For more information, see Setting Deployment Project Properties.
To associate the deployment project with your application project, you add the project outputs to the appropriate folder in the File System Editor. What are project outputs? They are the files that your application produces when it is built. For example, an .exe file is the primary project output for a Windows Application project, and a .dll file is the primary output for a component project. In addition to the primary output, any dependent files are also included as project outputs.
Note Although the dependencies for a project output are detected, there are some cases where the dependent files cannot be included in your setup. These cases are discussed later on in this article in the section What Else Do I Need to Distribute?.
You can also add files from your application project to your deployment project in the File System Editor. For example, you might want to install help files or HTML pages that are not compiled into the application. For more information on using the File System Editor, see File Installation Management in Deployment.
The final step is to build your deployment project. When you build the deployment project, any dependent projects are also built, so that you are including the most recent versions. After the project is built, you are ready to install the files on another computer.
After your deployment project has been built, you will need to find the .msi file for your application in order to distribute it. The Output file name field in the Deployment Property Pages dialog box determines the location; the default is \Documents and settings\Yourloginname\Visual Studio Projects\Projectname\Project Configuration\Projectname.msi. The default Project Configuration is Debug; Projectname is the name of the deployment project.
With the default project settings, you will find four other files in the directory with the .msi file: Setup.msi, Setup.ini, Instmsia.exe, and Instmsiw.exe. Setup.msi is not your old familiar setup file, it is a wrapper for the .msi file and the Windows Installer bootstrapping application (also known as a bootstrapper). The bootstrapping application installs the correct version of Windows Installer if it is not already installed before installing the .msi. The Instmsia and Instmsiw files are the Windows Installer bootstrapping-application files — the first is for installing on Windows 95, Windows 98, and Windows Millennium Edition; the second for installing on Windows NT. The Setup.ini file contains the location of the bootstrapping-application files.
Tip If you are sure that the correct version of Windows Installer is already present on all computers where your application will be installed, you can exclude the bootstrapper files by changing the Bootstrapper property in the Deployment Property Pages dialog box. For more information, see Build, Configuration Settings, Deployment Project Properties Dialog Box.
When distributing your application, all of the output files should be distributed. End users should install your application by running the Setup.msi, rather than the .msi file, to insure that Windows Installer will be installed if necessary.
Just as Visual Basic 6.0 applications had dependencies on the Visual Basic runtime and other components, Visual Basic .NET applications also have dependencies. For the most part Visual Studio does a thorough job of analyzing and including dependencies, there are two specific dependencies that you need to be aware of: The .NET Framework runtime, and Microsoft Data Access Components (MDAC). Any application created with Visual Basic .NET requires that the .NET Framework runtime is already present on the target computer, and any application that accesses data also requires MDAC.
By default, setups created with Visual Studio .NET are unable to install the .NET Framework or MDAC as a part of the installation; they must be preinstalled. There is, however, an add-in for Visual Studio 2003 that allows you to bootstrap both the .NET Framework and MDAC.
The Visual Studio .NET Framework Bootstrapper Plug-in modifies the behavior of the Setup project's Bootstrapper property to include the .NET Framework bootstrapper as well as the Windows Installer bootstrapper. The .NET Framework redistributable and the appropriate Language pack are then packaged with your application; a launch condition checks for the correct version of the .NET Framework at install time and if necessary, installs it before installing your application. For more information, see the section "Installing the .NET Framework with a Setup Project" in the article Using Visual Studio .NET 2003 to Redistribute the .NET Framework.
In Visual Basic 6.0, customizing a setup required either modifying the setup script file or modifying the Setup1.exe project template used by the wizard. In either case, the process was not simple and was prone to errors.
In Visual Basic .NET, customizing a setup is accomplished in your deployment project by using the deployment editors. In addition to the File System editor mentioned earlier, editors are also provided to:
- Work with registry settings.
- Define file types and associations.
- Customize the installation user interface.
- Specify launch conditions.
- Add custom actions that can perform advanced installation functions.
For more information, see Editors Used in Deployment.
Tip To quickly open and switch between the deployment editors, you can use the Deployment toolbar that is displayed at the top of Solution Explorer whenever a deployment project is selected.
Managing File Installation
In addition to specifying the location of files on a target computer, the File System Editor can also be used to create shortcuts (on the desktop or in folders) or to install different files based on conditions discovered at install time. For more information on the File System Editor, see File Installation Management in Deployment.
Specifying Registry Keys and Values
The Registry Editor allows you to specify registry keys and values that can be added to the registry of a target computer during installation. Unlike the Visual Basic 6.0 registry functions that only allowed access to a small subset of the registry, the Registry Editor gives you complete access and control. You can even set conditions to specify different registry keys or values based on information retrieved during installation. For more information on the Registry Editor, see Registry Settings Management in Deployment.
Associating File Types
The File Types Editor allows you to create file associations on a target computer during installation. For example, if your application uses a specific file extension for its files, you can use the File Types Editor to register the file type so that any file with that extension will be opened in your application. For more information on the File Types Editor, see File Types Management in Deployment.
Displaying Additional Dialog Boxes
In addition to the standard set of dialog boxes displayed during installation, the User Interface Editor allows you to display a number of optional dialog boxes. You can add and customize dialog boxes to gather user input, verify a serial number, register a product, display a license agreement, and much more. For more information on the User Interface Editor, see User Interface Management in Deployment.
Specifying Launch Conditions
Launch conditions provide a means to inspect a target computer and specify conditions that must be met in order for installation to continue. For example, if your application requires a specific operating system version, you can add a launch condition to make sure that the correct version is installed. Launch conditions can be set to search for any file, registry value, or component; several predefined launch conditions are also provided for common tasks. For more information on the Launch Conditions Editor, see Launch Condition Management in Deployment.
Adding Advanced Custom Actions
Custom actions are perhaps the most powerful way to customize a setup. In short, a custom action is a program that is run at the end of installation. A custom action can do just about anything you can imagine, from launching an application to setting up a database or message queue. Custom actions can be contained in a .dll or .exe file, a script, or a .NET installation component. For more information on the Custom Actions Editor, see Custom Actions Management in Deployment.
Although different than in Visual Basic 6.0, deployment in Visual Basic .NET is ultimately easier and much more powerful. Take some time to discover the powers of deployment—run the Setup Wizard, create a few deployment projects and experiment with their properties, and explore the documentation.
Tip There are a number of step-by-step topics in the documentation that can guide you through some more advanced tasks. For more information, see Deployment Walkthroughs.