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
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:
- 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.
- 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.
- If your application has a SQL database, you then have to create it, and perhaps populate some domain tables by executing SQL scripts.
- You might also have to create some security settings for SQL and your application in general.
- 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:
- Using the command xcopy for deployment, also known simply as XCOPY deployment.
- Using the Copy Project option in Visual Studio 2003.
- 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
FIGURE 4-2 The Copy Project dialog box
And finally, option 3, the creation of a Web Setup Project, is shown in Figure
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
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
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:
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 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
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
Note To try it, you just have to delete your
database, delete your IIS Web application and settings, and then publish using
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
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.