At one time or another, we've all sat through an InstallShield process or downloaded something from the Web that began installing itself, or installed something that was packaged using the Microsoft installer tool (packages with .msi file extensions).
When you can't deploy your applications simply by dragging the files from the development machine to the deployment machine, you need to use some extra tools to create deployment and installation packages to help distribute your applications.
The next section of the chapter deals with creating and deploying automated installations using the Visual Studio .NET 2003 Setup project type, built specifically for a web application. Although you can use this project type to create installation packages for Windows Forms, that aspect of the tool will not be discussed in this chapter.
Creating a Setup Project
This next section covers the creation of an MSI (Windows Installer) package that will install your website on a server. There are many different reasons why you would want to package your website in a self-installing executable.
The first and probably most common reason is that your server deployment environment is incredibly secure. The only way you can install applications on that server is to provide someone with access to your server (either IT or configuration management) with an easy-to-install installation package and instructions for how to answer the prompts.
A second scenario is that your application is a website that you sell "shrink-wrapped" to other clients. For example, you might produce a bug-tracking application that installs on the web servers in other IT departments. In that case, you would definitely want to provide an easy-to-use installation package that someone could run from a CD and have everything configured properly.
To discuss the creation of a complete setup project, the first thing to be done is to create the website to be deployed. The website will be simple so that you can focus on the deployment of that website and not the development of the site itself.
The first step is to create a new Web Application project. Call this project Deployment. Don't worry about changing any values or setting up anything else. Next, add a new class library to the solution called DeploymentLibrary. Add a reference from the Deployment project to the DeploymentLibrary project.
Now that you have a website set up and you've got a class library that it references to create a representation of some kind of dependency, create the setup project. Add a new Web Setup project to the solution and call it DeploymentInstall.
You will be presented with a new view that contains a folder called Web Application Folder and some properties for that folder in the properties window. This new view is shown in Figure 26.2.
Figure 26.2. Empty web setup project.
There is a plethora of properties that you can set on the web application folder. This view, called the File System view, represents the file system as you would like it to be after the installation has completed. As such, the properties of the Web Application Folder are those that you want to have set on your application when it is installed and configured in IIS. Table 26.1 is a short list of some of the more commonly used properties of the Web Application Folder.
As you can see, you have quite a bit of control over the installation of your website using a setup project. To add the files that your website is going to install, right-click the Web Application Folder and choose Add, Project Output. You will be prompted for the kind of project output you want. Select Primary Output to add the website's bin directory. Do the same thing again, except choose Content Files this time. This will include all the .aspx, .asmx, and .ascx files from the website.
Highlight the Content Files from Deployment (Active) node and look at the properties window. You should see a host of configuration options that control how, when, and where you install that particular item.
This is just a small number of the things that a setup project can accomplish. Take a look at the View, Editor menu options. You'll see the following different kinds of views that you can examine within your setup project:
Open the User Interface section. You will see a hierarchical view of dialogs and other pieces of the user interface, such as the progress dialog, and so on. Figure 26.3 shows what the default user interface of a setup application looks like.
Figure 26.3. The default user interface of a web setup application.
There is too much that you can configure in a setup project to cover in one short chapter on ASP.NET deployment. To keep things short and to the point, this chapter discusses some of the more interesting ASP.NET installation features and lets you play with the remaining settings on your own. The setup project really is quite intuitive and very easy to use. When you start to find out everything the setup project can do, you'll be really surprised at how powerful it is.
To demonstrate some of these powerful features, we're going to password-protect the setup project so that only people who have the proper password can install the application. This isn't exactly practical, but it shows you just how easily you can customize your setup project.
First, get into the User Interface view and right-click the standard install's Start node. Choose Add Dialog and select Textboxes (A). Make sure that you move that dialog to the top so that it appears before the Address input dialog. Although you can't actually drag and drop buttons and things onto a design surface, you can control the behavior of the dialog via properties. Set the BannerText and BodyText properties to anything you like. Table 26.2 shows some of the properties for this dialog.
The most important part of this dialog is the Edit1Property value SUPERSECRET. You can think of this as a variable. Whatever the user performing the install enters when prompted for Edit1 will be stored in a property called SUPERSECRET that will be accessible to other parts of the installation system for querying.
One of those parts is a launch condition. A launch condition is a prerequisite that must be met in order for the installation to actually begin. By default, ASP.NET setup projects require a minimum version of IIS and a minimum version of ASP.NET. You can require anything you like in order to prevent your application from being installed in an unsuitable environment.
With that in place, you have a launch condition that prevents the installation from being launched if the user-entered property called SUPERSECRET is not equal to the value password.
Build the installation project so you can test it out. The actual MSI file will be in the project's bin\debug directory. Executing the setup project, you'll see the opening welcome screen, as illustrated in Figure 26.4.
Figure 26.4. The opening welcome screen of the Installation Wizard.
Clicking on the Next button, you are prompted for the password, as shown in Figure 26.5. Take a good look at this dialog, and remember that you had to set up only a couple of properties in order to get it to appear.
Figure 26.5. The custom password prompt dialog.
Note that we obviously didn't enter the correct password. The wizard will continue gathering information from the user, and then when it gets to the step where it validates all the launch conditions, the error message shown in Figure 26.6 appears just before the installation aborts.
Figure 26.6. The error message indicating an install abort due to invalid password.
You've now seen that with a few changes to some properties and just a small amount of effort, you can turn your stock, default installer into an incredibly powerful deployment tool. Unless you need the most state-of-the-art features for your deployment package, you shouldn't need to use any third-party deployment packaging tools because the one that you get for free in Visual Studio .NET 2003 is sufficient for the majority of most deployment needs.
Deploying a Setup Project
Fortunately, deploying a setup project is one of the easiest parts of the whole deployment process. To deploy your setup project, you simply transfer the MSI file to the destination machine, and then run it. If the destination machine is in a data center or a DMZ, or you can't get physical console access, installations are typically performed using Terminal Services.
If you have additional tasks to be performed as part of the installation, you can bundle executable files or assemblies with special installer classes embedded in them. With the Custom Actions section of the setup project, you can specify pieces of code that can take care of specialized configuration needed just for your project to run during different portions of the installation. You also don't have to worry about the global assembly cache. You can specify the global assembly cache as a target folder and your code will be registered there without a problem.