Deployment Methods within Visual Studio

With the early releases of Visual Basic, if you wanted to install your custom software using a setup program, you either had to write it yourself or use a purchased tool. Deployment tools did eventually appear in Visual Basic, especially the infamous "Package and Deployment Wizard." This canned setup program was written in Visual Basic, and you could enhance it to meet your own custom deployment needs. But it wasn't easy. And the rest of the world was already adopting the new "Windows Installer" platform for standardized deployment via ".msi" files. The Package and Deployment Wizard used the older ".cab" file format. Even for someone like me who actually enjoyed programming, the need to write effective installation programs sometimes made life ugly.

When Visual Basic .NET 2002 came out, life became beautiful again. Visual Studio included tools that let you target the Windows Installer technology, just like the big boys used. Sure, it was a stripped-down version that only let you release the simplest of applications, but third-party vendors have to have some fun.

These days, Visual Studio includes several deployment methods, a tribute to the different types of applications, the different types of users, and the different types of secure environments that a programmer may need to target. Read through each of the available methods to see which one best meets the needs of your program. I've already made my selection for the Library Project, which I'll reveal in a public ceremony about halfway through this chapter.

Direct ASP.NET Deployment

ASP.NET applications are clearly different from desktop applications. One big difference is that, for the final user, ASP.NET applications don't really have any deployment. You just browse to the right web site and you're using the application. But there is still deployment needed for the hosting web server.

If your web server has Microsoft FrontPage Extensions installed, you can install a compiled ASP.NET application right from the comfort and safety of your development environment. I just glossed over it back in Chapter 22, "Web Development," but Visual Studio presents you with the option to put a web application on a real live web site when you first try to create the ASP.NET application. In the New Web Site form, you can select an HTTP URL as the development location, as shown in Figure 24-1.

Figure 24-1. Getting an early start on that web site

Because you will be interactively developing your web site, you might not want to use this method on a production server. Instead, you can develop locally in a directory or on a development web server, and then later publish the site to the production server. This is just as easy as setting the HTTP location from the start. With the web site open in Visual Studio, select the Build Publish Web Site menu command, and specify the URL of the new web site. No separate setup program is required.

ASP.NET is careful about how it handles the files in your application. It will not publish your source code. It will copy your web.config file to the server (it's a required file), which may contain your database connection string. But a properly configured ASP.NET web server will keep this file from prying eyes.

XCopy Deployment

Compiled .NET assemblies contain a manifest that fully describes the assembly and its needs. This means that you can copy any assembly to another system that has the correct version of the .NET Framework installed, and as long as the other files the assembly needs are copied as well, the program will run. This is called "XCopy deployment" because you can use the command-line XCopy command to move the files.

You may be thinking, "Well, duh! An EXE assembly is a real Windows program. Of course it will run when I copy it to a new system." Well that's true. But it wasn't true for older Visual Basic applications. The ActiveX controls used by COM-based Visual Basic applications had to be registered in the Windows Registry before they could be accessed at runtime. Older Visual Basic programs also required that the Visual Basic runtime libraries be installed. The .NET Framework must also be installed for .NET programs, but because the Framework is managed automatically by the Windows Update system, this is not as big of a headache.

What I've taken too many sentences to say is that in most cases, you can install a .NET application on a workstation just by copying the program, and maybe a few support files, to a directory. I'm not saying that this is how you should install programs. Actually, I would be shockedshocked!if I discovered any of my programming friends using this method in a real business environment. But .NET makes this deployment option available to you if you don't want to be my friend anymore.

If you do use XCopy deployment, you probably won't have any issues with security or administrative limitations that may be imposed on the workstation. Chances are, if you're installing software using the XCopy command, or by dragging-and-dropping files, it's probably because you are friends with the owner of the workstation, and it's really none of my business who you want to have as your friends.

Windows Installer Deployment

Windows Installer is the official installation system provided by Microsoft. It serves as the base system for standard Visual Studio-generated installation packages, and also provides the underpinnings for most popular third-party installation tools.

Before Windows Installer, each installation package vendor pretty much did things as they saw fit. But this meant that installed products sometimes clobbered each other, because one software package didn't necessarily look out for files installed by another tool. Repairing such damage was difficult for the user, who usually didn't even know which files were installed or updated.

Microsoft sought to change that with Windows Installer. One of the key features of the system is its database of updated and installed files. It also supports a full uninstall/restore and rollback capability, so that any failure can be fully undone, restoring the system to its previous state. Other features include support for patching, rebooting, custom enhancements, some limited user interface and prompt design, the ability to repair or "heal" a previously installed but damaged program, and install-on-demand, which keeps features or full applications on the installation media until the user tries to use that feature.

Windows Installer version 3.x is the latest version for Windows XP and other parallel Windows systems. (You can still get version 2.x for some older Windows systems, like Windows 98.) Windows Vista will introduce version 4.x of the installer technology.

The heart of the Windows Installer system is the MSI file (with an .msi file extension), the single file that contains all the files and instructions needed to install, update, and uninstall a software product. Visual Studio can create Setup projects based on the MSI standard, although you can't use some of the more advanced features of Windows Installer through Visual Studio. Still, if your needs are simpleand most business-level software written in Visual Basic has simple installation needsVisual Studio is probably all you need.

Building a setup project is just as easy as creating regular Visual Studio development projects. But first, I need something to set up. For the discussion in this section, I've created a desktop application. Well, not a very good one. I simply created a new WindowsApplication1 project with its default Form1, and saved it to my C:\temp folder. All it does when you run it is display Form1.

To create an MSI installation file for a Visual Basic project, open that project in Visual Studio, and use the File Add New Project menu command to add a setup project to the entire solution that contains your original project. Figure 24-2 shows the Add New Project dialog. Select the Setup and Deployment project type, and then the Setup Wizard template to create a setup program for the active project. Set the Name and Location fields according to your needs, and then click OK.

Figure 24-2. Adding a setup project to your solution

The Setup Wizard appears, leading you through five steps to peace, harmony, and a working MSI file.

Step 1

The first wizard step just says "Welcome," so click Next and get on with the real work.

Step 2

Step 2 asks you for the type of setup project to generate. Personally, I think it could have figured this out from the content of the already loaded projects, but if the wizard did everything, why would the world need programmers like us? There are four choices, shown in Figure 24-3.

Figure 24-3. Choosing the type of setup program

The first two choices create full setup files for either desktop or web-based applications. (The web-based setup would be delivered to a web site administrator for installation on the server.) Merge modules let you create a portion of an installation that can later be merged into a full MSI file. This is a good choice if you are designing a library that will be used for multiple applications, but it's useless on its own. The CAB file option creates an archive of files that can be installed using slightly older file distribution technology. It's also the distribution system used for handheld devices. Because I'm targeting a desktop application, I'll choose Create a setup for a Windows application and click Next.

Step 3

While you can create a setup program that simply installs miscellaneous files scavenged from your hard disk, you usually build a setup project based on the files or compiled output of other projects. The third wizard step prompts you to include elements from the other projects found in the active Visual Studio solution. I've chosen to include the compiled EXE file from my desktop project, as shown in Figure 24-4.

Figure 24-4. Choosing project elements to include in the setup

I generally don't want to include my source code in the Setup project, so I'll leave that element unchecked. But the "Content Files" item may be useful. If my project had a compiled online help file (with a .chm file extension), I could have added it as a standard content file to the main project via the Project Add Existing Item menu command. That file would be classified as Content, and could move into this Setup project through the "Content Files" selection. But there are other ways to include online help in the installation, which we'll see in the next step. For now, I'll stick with the "Primary output" selection, and click the Next button.

Step 4

In this step, you can add any additional non-project-specific files you want to the setup project (see Figure 24-5). "Readme" files, online help content, license agreements, pictures of your kids, and pretty much anything else can be included here. I've got nothing more to add. Click Next.

Figure 24-5. Add those other files that have always wanted a chance at Setup project stardom

Step 5

The final step displays a summary of the choices you made (see Figure 24-6). Well, that wizard was pretty easy. We had to do work in only three of the five steps. Click Finish to complete the wizard.

Figure 24-6. Confirming our choices for the setup project

After the Wizard

Once the wizard completes, the primary interface for Visual Studio setup project design appears in the development window. Figure 24-7 shows Visual Studio displaying the newly generated setup project for WindowsApplication1, another project that also appears in the Solution Explorer panel.

Figure 24-7. A setup project within the development environment

The main window in Figure 24-7 is one of several "editors" that let you customize the setup project. You can access each editor through the View Editors menu command, or by using the toolbar buttons in the Solution Explorer panel.

• File System Editor. That's the editor you already saw in Figure 24-7. It presents a standard folder/item view of portions of the target system's file system. Through this hierarchy, you place files (the EXE output from your main project, help files, configuration files, shortcuts to any of these files, etc.) into special folders (Application Folder, User Desktop, Program Files, Fonts, the Start Menu folder, and others). If you don't see a folder you want in the File System on Target Machine panel, use the Action Add Special Folder menu command to include it in the list. Besides the standard special folders, the Add Special Folder menu includes a Custom Folder option that lets you create a specific folder anywhere on the target system.

• Registry Editor. This editor displays a truncated hierarchy of the registry hives. Any keys or values added here will be created in the user's registry during installation.

• File Types Editor. This editor lets you define associations between a file extension (such as ".txt") and specific programs or actions. Any custom action, such as Open or Print, can be linked to any command text you wish, including commands that target the primary assembly being installed.

• User Interface Editor. The default setup project includes a few forms that prompt for things like installation location and confirmation that the installation should occur. You can insert additional dialog boxes into the flow of the installation. But beware: You will not be adding full Visual Basic-enabled forms. Instead, you will choose from a few predefined dialogs (such as the "License Agreement" dialog, or the "4 Radio Buttons" dialog), and set the dialog properties to configure the display text of each dialog field or prompt. Each user entry field/control includes a named value that you use in the other editors to limit a specific installation action. For instance, you could monitor the value of a user-prompted checkbox, and if the user didn't check it, you could withhold the installation of certain files that were associated with that checkbox.

• Custom Actions Editor. If you need the ultimate level of control, you can add a custom action, a call to an external program or script, that runs at a certain point in the install (or uninstall) process.

• Launch Conditions Editor. If the target workstation must be in a certain state before you can successfully install the project, this editor lets you define the limiting conditions. By default, the installer adds the .NET Framework as an installation condition; the Framework must be installed before the project can be installed. You can look for specific files or registry keys that must be present before installation begins. For instance, you might want to confirm that the target database drivers are on the system before you install a database-dependent application.

Generating the MSI File

Once you've set up your project through the various editors, you output the final MSI file by building the solution (via the Build Build Solution menu command). The MSI file appears in the location specified in the setup project's properties (Project Properties). This file contains all the instructions and content required to fully install the application on the target workstation.

ClickOnce Deployment

Visual Studio 2005 includes a new deployment method called ClickOnce. It is designed to provide the ultimate in setup deployment ease for desktop (Windows Forms) applications. It still involves a wizard, darn it, but for basic installations, that's all there is to it. Once your application is "published" through ClickOnce, the user can install it directly from a web site or other stored location.

This sounds like a standard MSI installation, but it is different in several ways:

• ClickOnce deployments can be installed even if the current user does not have local administrative privileges. Many software installs affect key files in the Windows and Windows\System32 folders, or in other important but restricted folders. If you are a developer, it's likely that you never experience this problem because you are the administrator on your own workstation. But in IT department-managed organizations with many users, there is a benefit in reducing the privilege level of individual users. One negative side effect of this is that an administrator must be present to install any software. But that's not the case with ClickOnce. Is your entire IT department out to lunch? (I mean that literally.) No problem. Any ClickOnce-published application can be installed by any user. The software is installed in a "sandbox" that protects the system and other applications from the ClickOnce-installed program's villainous intents.

• A ClickOnce-deployed application can trigger its own automatic software updates. If configured in this way, the program will check the original deployment location for a new version each time it runs. If there is a new version, it will be installed automatically without the user having to do a thing.

• ClickOnce applications are designed for ease of installation. With an MSI-deployed application, you need to download the MSI file and process it through the Windows Installer system. Although you also have to download a ClickOnce deployment, it happens more or less transparently. A ClickOnce-published application can be configured so that it looks like an extension of a web page: Click a link, and the program immediately runs, displaying its main form to the user. (There may be some delay as the program is downloaded over the Internet.)

That sounds great. But it's not all peaches and cream. Because ClickOnce-enabled applications (by default) run in their own sandbox, they are limited in their access to some local resources. Also, to fully support all of the automatic-updating features, you must add additional code to your application that performs the actual update. (The My.Application.Deployment property provides access to these features.)

To deploy your project via ClickOnce, use the Build Publish menu command in Visual Studio. After asking you some very basic questions about where the user will obtain the deployment file (from a web site, a network folder, or a CD/DVD), Visual Studio generates the installation file and makes it immediately available for use.

Of course, that method only gives you the most basic installation options. It makes the primary EXE or DLL of your project (and its dependencies) available for installation on the target workstation, but that's about it. If you want more control over the publishing process and the components it will include, use the Publish tab of your project's properties, as shown in Figure 24-8.

Figure 24-8. The world of publishing just a mouse click away

This panel includes fields that let you set the version number for the published installation package. If you modify this version number and republish the application, the custom deployment code you added to the application can detect the new version and initiate an update from the distribution location.