Chapter 4: From 2003 to 2010: Deploying an Application

This chapter is taken from book "Moving to Microsoft Visual Studio 2010" by Patrice Pelland, Pascel Pare, and Ken Haines published for Microsoft Press.

After reading this chapter on deployment techniques, you will be able to

• Deploy a Web application and an SQL database using Web Deployment Packages.
• Deploy a Web application using One-Click Publish

Deploying a Web application is never easy-it should be, but it never is. Whether you are trying to deploy to your monthly paid host company or to a datacenter, you usually have to push the files to some location using FTP, using another custom upload tool, or packaging them in a .zip file. Then someone-either you or a system engineer-has to perform other configuration steps so that your users can hit your Web application successfully. This chapter will bring you the latest and greatest (and easiest) ways to deploy your Web application, and it will show you how to do so while having more control and going through fewer manual steps. It will also offer you comparisons with all three previous versions of Microsoft Visual Studio.

Visual Studio 2010 Web Deployment Packages

In this chapter, you'll deploy your application using Web Deployment Packages. You'll also see some of the pain points of doing this that were present in previous versions of Visual Studio. We'll take the examples mentioned in this chapter's introduction and go through the different steps one had to go through to deploy the application. Then we'll compare how it is done in each version of Visual Studio from 2003 all the way up to 2010. If you installed the companion content at the default location, you'll find the modified Plan My Night application at the following location: %userprofile%\Documents\Microsoft Press\Moving to Visual Studio 2010\Chapter 4\Code. Double-click the PlanMyNight.sln file.

Let's start with the example of deploying to a monthly paid shared hosting company. Here are the big steps one would have to take to deploy a Web application in such a scenario:

1. Get the files that are needed for your application to your Web hosting company using FTP or their custom control panel upload tool. If you want only the files needed to execute, you need to sort them out and know exactly which ones you need and transfer only those files.
    
2. After the files are copied, you have to go to the control panel and make sure all the files are in the right place and then go through the configuration of your application for various Internet Information Services (IIS) settings. Depending on the host company, you might have to create an application in IIS, select the application pool and its type, and so forth.
    
3. If your application has a SQL database, you then have to create it, and perhaps populate some domain tables by executing SQL scripts.
    
4. You might also have to create some security settings for SQL and your application in general.
    
5. Finally, you'll probably have to modify your web.config to match some of the servers and modify some database-related configuration options such as your connection strings.

Similarly, in an enterprise you often have to deploy to datacenters and on servers for which you won't likely have access to physically or even remotely with remote desktop. In most enterprises, you won't even have a chance to talk to the engineers doing the deployments because often it happens during off-peak hours and in other time zones. And the only thing they have is the reliability of your scripts and your deployment documentation. This means your deployment scripts must be bulletproof and your deployment documentation needs to be thorough-because it will be tested by other engineers with little or no knowledge of your project-so that nothing is assumed.
With any deployment technologies, the ideal situation is to come up with the deployment packages as you develop your product. If you wait until after the code is completed, it is extremely hard to do a good job and your work is a lot more error prone. Here is where Visual Studio 2010 and the Web Deployment Tool come in handy.

Visual Studio 2010 and Web Deployment Packages

Using the Plan My Night application and Visual Studio 2010, you'll examine how as a developer you can deploy your Web application and get it to a state where you can deploy it with confidence. Using the tools, you'll be able to test it and refine it using IIS on your machine and then deploy it to your shared hosting service. In an enterprise, you do this and then add the deployment package creation in your MSBuild or TFSBuild processes.

What Was Available Before Visual Studio 2010

In Visual Studio 2003, your options to deploy Web applications without buying a specialized tool were roughly limited to the following three:

1. Using the command xcopy for deployment, also known simply as XCOPY deployment.
2. Using the Copy Project option in Visual Studio 2003.
3. Using the Visual Studio 2003 Web Setup Project option.

Options 1 and 2 were useful for simple deployment, but when things got more complicated the only options were either option 3 or using a product like InstallShield.

Option 1 was basically a process of manually copying the necessary files using the command xcopy and then doing the rest of the configuration either through batch files, your favorite scripting language, or manually.

Option 2 involved doing something similar to option 1, except that you had fewer decisions to make as to which files were going to your server and how they would get there. You could use the FrontPage extensions or a file share, and you could choose to just use the files needed to run the application or all the files in the project or folder in which your application was residing. You still had to configure similarly to option 1.

Option 3 enabled you to create an MSI and configure pretty much everything for your Web application, but it didn't give you lots of control over IIS settings, SQL databases, and other things that most Web applications use. And on top of that, it wasn't as easy and reliable as one would like.

Look at Figures 4-1, 4-2, and 4-3 for the three most common methods to deploy a Web application in Visual Studio 2003. Figure 4-1 shows the first option listed.



FIGURE 4-1 The XCOPY deployment screen

Figure 4-2 illustrates option 2, the Copy Project method.



FIGURE 4-2 The Copy Project dialog box

And finally, option 3, the creation of a Web Setup Project, is shown in Figure 4-3.



FIGURE 4-3 The New Project dialog box, showing the Web Setup Project option

In Visual Studio 2005 and 2008, new notions regarding Web applications started to emerge. Starting in the Visual Studio 2005 era, a Web application could be created in two different ways. It could be created as a Web site directly in the file system-on disk and without a project file-or as a Web Application Project, like many other normal project types.

Note The Web Application Project became part of Visual Studio 2005 as an add-on a few months after the product shipped. People requested that Microsoft have both options: a Web site on disk and a Web Application Project similar to the proven project template that had shipped in Visual Studio 2003. Those projects are easier to manage in an enterprise environment and can be easily integrated with MSBuild.

The Web Deployment Project was created as an add-on in Visual Studio 2005 and 2008. The feature set is pretty much the same in both versions except that the Visual Studio 2008 version had many bug fixes and improvements.
The Web Deployment Project doesn't alter the Web site or the Web Application Project. Instead, it takes one as input and creates an entirely different project. In fact, it never touches the original source code, but rather it creates a new project with the necessary files based on the configuration options you selected. The Web Deployment Project is only a project file and nothing else. With a few dialogs, it enables you, the developer, to specify how and where you want to deploy your application.

At build time, it then mainly uses two utilities to turn those options into a Web site matching your selections. Those two command-line tools are called aspnet_compiler and aspnet_merge. In a nutshell, the first one compiles your projects composing your Web application and the other one merges their output and copies the files either to a folder or to a virtual folder in IIS.

You can have one deployment configuration per regular configuration (debug and release) and any custom configuration you might create. Figure 4-4 shows the beginning of the Web Deployment Project creation.



FIGURE 4-4 Add Web Deployment Project dialog

Now let's look in Visual Studio 2008 at the Web Deployment Project properties. Figure 4-5 gives you an overall sense of what it can help you with.



FIGURE 4-5 Web Deployment Project property page

Because it is a normal project file with MSBuild directives, you can modify "pre" and "post" build steps as well as run additional scripts. To do that, you have to edit the project file and modify the appropriate MSBuild targets. Finally, look at Figure 4-6 for a fragment for the PlanMyNight Web Deployment Project project file in Visual Studio 2008.

FIGURE 4-6 Web Deployment package project file source

It might not be apparent, but even though the Web Deployment Project was a huge improvement over what was in Visual Studio 2003, it was still not easy enough, not inclusive of all needs, and not powerful enough. It was a good step. Here is where the new Web Deployment Packages, the new Web Application deployment project, and Visual Studio 2010 come to the rescue.

What Are Web Deployment Packages?

A Web deployment package is a compressed (.zip) file that contains all the necessary files and metadata to set up your application in IIS, copy the application files to their destination, configure the different applications in IIS, and set up related resources such as localization resources, certificates, registry settings, installing assemblies in the GAC, and, finally, setting up databases.

Those packages are then installed on the destination server using the msdeploy tool. You can read the latest news about the msdeploy tool here: http://blogs.iis.net/msdeploy/default.aspx. A good analogy to this type of solution is what MSIs and the Windows installer are for the client desktop.

Note InstallShield and the Wix Toolset are two other great solutions. They both have pros and cons, and they both can work with other types of applications. The msdeploy tool is simply more specialized and therefore a bit easier to work with. As of the writing of this chapter (May 2010), Wix 3.5 is not out yet and a change in plans potentially is taking the custom action for IIS 7 out of that release. If it does ship, it will be no earlier than July 2010. (To follow what is going on in the Wix world, read Rob Mensching's blog: http://robmensching.com/blog/. ) Therefore, the Wix toolset is not an option I would recommend just yet, unless you are installing on IIS 6. InstallShield is out already, supports Visual Studio 2010, and can definitely create good packages to deploy Web applications; however, it isn't free.
In Visual Studio 2010, you create your packages by creating settings in the Package/Publish Web tab of the project properties page. Those settings allow you to specify what you put into a deployment package. Let's see this in action.

1. Make sure you have the PlanMyNight solution opened. Then right-click on the PlanMyNight.Web project, and select Package/Publish Settings. Let's look at Figure 4-7 to make sure you are at the right place.

FIGURE 4-7 The Package/Publish Settings option

2. Now let's take a look at Figure 4-8 to look at the content of that tab and select the same settings for the PlanMyNight.Web application you have opened.




FIGURE 4-8 The Package/Publish Web tab

3. Similarly, in the Package/Publish SQL tab you can find the settings related to creating a package for your database. Click on the Package/Publish SQL tab, or click on the Open Settings link in the Package/Publish Web tab.

4. Click the Import From Web.Config button, and then copy the same string from the source connection string to the destination connection string. Make sure your SQL settings look like Figure 4-9. Save the file.



FIGURE 4-9 The Package/Publish SQL tab

5. Now it's time to build the package. Right-click on the project name, and select Build Deployment Package. The build process for the application will start. When it is completed, the output will become the input to the package's creation. If all goes well, the package should be created at the location you specified in the package settings.

6. The package folder should contain the package .zip file, a command file that invokes Web Deploy to make it easier to install the package from the command line, a SetParameters.xml file containing all the parameters passed to Web Deploy, and a SourceManifest.xml containing the parameters Visual Studio 2010 used to create the package.
You have just created the package using Visual Studio 2010, but packages can also be created by using MSBuild at the command line or MSBuild using Windows PowerShell or TFSBuild. Now if you have access to the server, you can take this package and the command file and deploy it. But if the server is a shared hosting company or another datacenter, you have to publish it differently. And here is where One-Click Publish can help.

One-Click Publish

One-Click Publish is a Visual Studio 2010 tool that allows you to deploy a package based on various technologies. Most importantly, it can use Web Deploy to publish the package you created in the previous steps. It can also use FTP and FrontPage Extension. Let's see what the Publish Profile looks like. To do so, right-click on the PlanMyNight.Web Web project and select Publish. You should see the dialog shown in Figure 4-10, which displays the Publish Profile information.



FIGURE 4-10 Publish Profile dialog

If you publish to a shared hosting company and have Web Deploy installed on its servers, the hosting company will give you the service URL to use-something like https:<sharedhost>:8172/MsDeploy.axd. Or you put the name of the server if it was on your intranet. Finally, the site/application corresponds to the IISWebSiteName/IISWebApplication. The bottom part of the dialog shown in Figure 4-10 is used to enter credentials, if needed, for your Web hosting company or your intranet.

Note To try it, you just have to delete your database, delete your IIS Web application and settings, and then publish using this tool.

You can do a lot more than use what the UI gives you access to. Integrating your deployment in your TFSBuild or MSBuild allows you to change many things at different steps of the process.
The options offered out of the box have been discussed here in this chapter. Of course, Visual Studio 2010 has many more ways to deploy other types of applications.

Summary

In this chapter, we reviewed many ways to deploy Web applications. You saw how to do it in the previous three versions of Visual Studio. You learned that you have a lot more control of the process and that it's a lot easier in Visual Studio 2010. Web Deploy is a new technology that allows Web developers to become really proficient at preparing and deploying complex installations and databases in an easy and extensible manner. As you witnessed in these short examples, you can deploy your software in a confident and timely manner. It is a great improvement over the XCOPY deployment most of us had to work with in the early days of ASP.NET.

Finally, remember to keep abreast of all the changes in the msdeploy technologies by following the teams' blog at http://blogs.iis.net/msdeploy/default.aspx . The Wix Toolset is also well integrated into Visual Studio and is therefore another excellent alternative.