Tải bản đầy đủ - 0trang
“bin-deploying” ASP.NET MVC libraries
Figure 19-1. The menu option to add a folder containing the ASP.NET MVC dependencies to your
When you choose this option Visual Studio will let you select which dependencies you
want to include in your project. Choose the ASP.NET MVC option, as shown
in Figure 19-2, and click OK.
Figure 19-2. Select ASP.NET MVC
Visual Studio will then create a new folder called /_bin_deployableAssemblies that
contains the framework assemblies to include in the deployment (Figure 19-3).
Figure 19-3. The new _bin_deployableAssemblies folder
What Needs to Be Deployed | 397
Now when you publish the website, Visual Studio will deploy the assemblies in this
new folder along with the rest of your application.
Static content can refer to any type of file, but the majority of these files will almost
in your site’s folder structure, the default ASP.NET MVC project templates create
and other content in. Therefore, if you use this out-of-the-box convention, these three
folders will contain all of your site’s static content.
Be sure to set the Build Action property on each static content file in your
Visual Studio project to Content so that Visual Studio is aware that it is
static content that should be deployed along with your site.
What Not to Deploy
If you’re following the conventions defined in the default ASP.NET MVC project templates, just about every ASP.NET MVC website deployment will look similar to the
directory hierarchy shown in Figure 19-4.
Figure 19-4. Conventional ASP.NET MVC deployment hierarchy
Note that this directory structure is very different from the set of files that you work
with in the application’s Visual Studio project (for example, the project shown in
398 | Chapter 19: Deployment
Figure 19-5. Default ASP.NET MVC project structure
More specifically, the deployed application will not include any of the source code files
that define the application’s logic. Since the project is compiled before it is deployed,
these source code files are already “included” in the deployment in the form of the
application’s compiled assemblies in the /bin directory. With this in mind, you’re free
to create any folder structure that you please to store and organize your source code
files, since these folders will not become part of the deployed application.
Databases and Other External Dependencies
Though almost every ASP.NET MVC application deployment will include a directory
structure similar to the one shown in Figure 19-5, this is where the similarities between
ASP.NET MVC application deployments usually end and the unique deployment needs
Most web applications will also depend on things other than the physical files that get
deployed to the server, such as the ability to store data in and retrieve it from a database,
or to interact with a web service. These dependencies only increase as applications
become less tightly coupled and distributed or service-oriented architectures grow more
While exploring the details of how to coordinate the deployment of your website with
these systems is well beyond the scope of this book, the high-level discussion of how
to plan for these kinds of deployments is not. Below is a list of questions you can ask
to help discover the dependencies and tasks that your application deployment requires:
1. What system-level applications and APIs does the application require (e.g., OS
version, IIS version, .NET Framework version)?
• Does any software need to be installed on the server?
2. What system-level folders or files does the application require?
What Needs to Be Deployed | 399
• Does the application require a specific folder path to anything? (This is usually
something that you should avoid.)
3. Does the application require a database?
• If so, have there been any updates to the database schema since the last release?
• Does the application use a particular database user? If so, is that user’s database
access properly configured?
4. What other servers or services does the application interact with?
• Are any networking changes required to access them (e.g., firewall rules, user
or role security)?
5. Do I have all of the appropriate licenses purchased and available?
Note that this list certainly does not include everything that you’ll need to consider in
order to have a successful release. These questions should, however, help address the
most common situations and get you thinking about any additional requirements that
your particular application may have.
What the EBuy Application Requires
To give an example of the thinking that goes into website deployment, let’s take stock
of what dependencies and configurations might be involved in deploying the EBuy
• System-level APIs and services. The EBuy application is a pretty basic application that doesn’t depend on any system-level APIs other than the .NET 4.5 Framework. It provides all its other API dependencies—including ASP.NET MVC 4—in
its /bin folder (which, of course, must be deployed).
• Views, scripts, stylesheets, and images. In addition to the assembly dependencies, such as the .NET Framework and the assembly that includes the application’s
logic, these artifacts are the most obvious dependencies that the application requires in order to function. We’ll need to be sure these files get copied along with
• A database. The EBuy website is a data-driven website, backed by an Entity
Framework Code First data model that requires a database to persist the application’s data.
• A place to store uploaded images. When users create a new auction listing, they
have the option to upload images of the item to display in the listing, and the
application must store these images somewhere. The actual location and method
of storing the image files may vary, depending on whether the application is hosted
on a single server, a server farm, or with a cloud hosting service such as Azure.
Regardless of where they are stored, the application must be sure to have both
“physical” access (i.e., network or filesystem access) to the location, and the
appropriate security permissions to read and write the images.
400 | Chapter 19: Deployment
Once we have answered all of these questions and made sure that we know everything
that must be deployed in order for our application to function properly, it’s time to
Deploying to Internet Information Server
Perhaps the most common ASP.NET MVC application hosting scenario involves creating and configuring a website using Internet Information Server (IIS). The good news
is that ASP.NET MVC applications are—for the most part—just like any other
ASP.NET application, so if you are already familiar with deploying an ASP.NET web
application to IIS, you do not have much to learn, and none of the steps should come
as a surprise to you. If this is your first time working with IIS websites or ASP.NET
applications, fear not—the following sections will walk you through everything you
need to know in order to get started.
Before we can create and deploy our website, we first need to ensure that the target web
server has all of the prerequisites necessary to host an ASP.NET MVC application. In
the early days of the .NET Framework, it took quite a few steps to get an ASP.NET
application and all of its prerequisites deployed to a web server.
Luckily, things have progressed to the point where the only prerequisite that needs to
be installed on the web server—other than IIS itself—is the .NET Framework (version
4.0 or greater).
Deploying the ASP.NET MVC Framework assemblies
The ASP.NET MVC 4 assemblies themselves also need to be available, but you have
two options for deploying those. You can either:
1. Run the ASP.NET MVC 4 installer as described in Chapter 1.
2. Include the ASP.NET MVC Framework assemblies in your application’s /bin folder
using the bin-deploying method mentioned earlier in this chapter.
If you plan to run many ASP.NET MVC 4 websites on a single server, it may make sense
to choose the first option: install ASP.NET MVC 4 once and not worry about it again.
However, there is no compelling reason to go this route other than saving the disk space
that the ASP.NET MVC Framework assemblies would occupy in each application.
In almost every scenario, it is advisable to choose the second option and deploy the
ASP.NET MVC Framework assemblies in your application’s /bin folder, just as you
would any other assembly that your application depends on. Deploying the assemblies
with the application makes it very easy to manage, maintain, and even upgrade each
individual website in isolation, without worrying about the effect that a server-wide
change might have on other sites.
Deploying to Internet Information Server | 401
Creating and Configuring an IIS Website
Creating a new IIS website is a very straight-forward process.
To begin, create the directory that your website will be hosted from; for example, C:
\inetpub\wwwroot\Ebuy. Then, open the IIS management application (Internet Information Services (IIS) Manager), right-click on “Default Web Site,” and choose the “Add
Application…” menu option, as shown in Figure 19-6, to display the Add Application
Figure 19-6. Creating a new IIS website
In this dialog (Figure 19-7), enter the name of your website (e.g., Ebuy) and the path
to the directory that you created in the first step (e.g., C:\inetpub\wwwroot\Ebuy).
Figure 19-7. The Add Application dialog
402 | Chapter 19: Deployment
You can feel free to leave the rest of the defaults in this dialog alone, but—just for good
measure—click the Select… button next to the “Application pool” field to pop up the
Select Application Pool dialog and verify that the default application pool uses version
4.0 of the .NET Framework (as shown in Figure 19-8).
If the default application pool is not configured to use version 4.0 of the .NET Framework, create a new application pool that does use .NET 4.0.
If you do not see version 4.0 in the list of available .NET Frameworks, it may mean
that the .NET Framework was not properly installed. Try reinstalling the .NET
Framework and, if necessary, running the %FrameworkDir%\%FrameworkVersion%
\aspnet_regiis.exe command to properly configure the .NET Framework inside IIS.
Figure 19-8. The default application pool configured to use .NET Framework version 4.0
Finally, click OK to have IIS create your website. Now you have a website that you can
deploy your site to!
Previous versions of ASP.NET MVC hosted in IIS 6 required special
configuration steps to allow for ASP.NET MVC’s extension-less URL
routing. This is no longer an issue, however, because ASP.NET 4 configures IIS to route anything without an extension directly to ASP.NET.
Note that if you are running IIS 7 or IIS 7.5 on Windows Vista SP2,
Windows Server 2008, Windows Server 2008 R2 SP2, or Windows 7,
you will need to apply a patch to your system.
Publishing from Within Visual Studio
Once you have your application created and configured in IIS, you have several
deployment techniques at your disposal.
The most accessible deployment technique is Visual Studio’s built-in publishing mechanism. To use it, right-click on the ASP.NET MVC project and choose the “Publish”
Deploying to Internet Information Server | 403
option from the context menu, as shown in Figure 19-9, to open the Publish Web
Figure 19-9. Opening the Visual Studio Publish Web wizard
To create a new publishing profile that will allow you to deploy your website, select
the “” option from the drop-down list in the Profile tab and give the new
profile a name (e.g., “Local IIS Website”). Then, since we are deploying to the local
filesystem, select the “File System” option from the list of available publish methods,
as shown in Figure 19-10.
Figure 19-10. The Publish Web wizard
The “File System” publishing option is only suitable if you are deploying
to a web server that you have direct filesystem access to via your network. If you are using a web hosting service, this is probably not the
case, so you will have to choose the FTP publishing approach to deploy
your website via the universal FTP protocol that all major web hosts
404 | Chapter 19: Deployment
Once you choose a publish method, the dialog will change to allow you to fill in the
rest of the configuration information needed for Visual Studio to publish using the
selected method. You can even save multiple publish configurations by choosing a
profile name from the publish profile list and then clicking the Save button.
When you’ve configured all of the required publish method options, click the Publish
button and Visual Studio will deploy your site to the location you specified. After it has
successfully deployed the website, Visual Studio will automatically open your browser
and navigate to the newly deployed site.
If you’ve been following along and trying this out on your machine, however, the deployment has probably failed—this was deliberate, in order to show you how to diagnose deployment issues! As it deploys your site, Visual Studio logs everything it’s doing
to the Output window. If it comes across any issues during deployment, they should
be displayed here.
For example, the deployment you just tried to execute may have failed due to the fact
that you do not have access to the C:\inetpub\wwwroot\Ebuy folder. If this is the case,
you should see the “ACCESS DENIED” message in the Output window. To fix this
error, update the security options on the target folder to include write access for the
current user and try to publish the site again. This time the publish should succeed and
a browser window should now open displaying your deployed site.
Copying files with MSBuild
As Chapter 18 showed, it’s a good idea to automate as much of your application development process as possible—and nowhere else is this more true than when it comes
to deployment. Though Visual Studio’s publishing mechanism is quite convenient,
having to open Visual Studio every time you need to deploy your site can become pretty
tedious. So, let’s see how we can reproduce what Visual Studio’s Publish Web wizard
does with an automated MSBuild script.
The following example shows an MSBuild script that first builds the solution using the
MSBuild build task, then copies the web application files to the destination website
directory using the Copy task:
Deploying to Internet Information Server | 405
In order to execute this script, open the Visual Studio Command Prompt, navigate to
the Ebuy solution folder, then execute the following command:
msbuild.exe deploy.proj /p:DeploymentDir="_[Path to Destination]_"
This will build the application and direct the output to a temporary build directory
(build in the current directory), then copy the contents of the _PublishedWebsites folder
that MSBuild creates for web applications to the destination folder of your choosing.
Executing database scripts with MSBuild
Both the Visual Studio File System Publish and the MSBuild deployment mechanisms
are great for deploying files, but what happens when your application depends on a
database that can’t be deployed with a simple file copy?
One of the great features of Entity Framework Code First is its ability to automatically
manage database versions for you—you can tell the framework to upgrade the database
automatically during the startup phase of your site whenever it sees that there has been
a model change that necessitates a database schema change. If, however, you are not
using this Entity Framework Code First feature, it is up to you to track and deploy any
database schema changes that may arise during the course of development.
When it comes to deploying database changes, you typically have two choices:
1. Recreate the entire database every time.
2. Keep each database upgrade in its own script file, and execute these files in order
to bring the target database up-to-date with the latest schema.
Naturally, Option 1 is the easiest solution during development—it is always less complex to build a database from scratch than to worry about upgrading an existing database. Unless you are developing toward your first production release, however, this
approach does not match your final production deployment and therefore does not
fulfill the spirit of continuous integration: testing the production deployment as often
as possible to discover issues as early as possible.
If you take Option 1 off the table, Option 2—multiple script files with incremental
database schema changes—becomes your de facto choice.
406 | Chapter 19: Deployment
Luckily, deploying either of these approaches is pretty simple using MSBuild and SQL
Server’s SQLCMD utility. To add SQL script execution to your build, add the following
lines to your MSBuild file:
These few lines will locate the SQL scripts in the path that you’ve provided ($(ScriptsDir)\*.sql), then execute the SQLCMD utility for each .sql file it finds against the SQL
Server instance configured in the $(SqlServer) property. Note that these scripts will
execute in the order in which MSBuild discovers them. This will be the order in which
they appear on the filesystem—by filename—so it often helps to apply a naming convention such as a number prefix on each of the script filenames.
Then you can execute the following command (all on one line) to have MSBuild execute
the SQL scripts and build your database automatically:
msbuild.exe deploy.proj /t:DeployDatabase /p:ScriptsDir=Scripts /p:SqlServer=.\SQLEXPRESS
The SQLCMD utility is installed as part of the standard Microsoft SQL
Server installation, but you do not need to have Microsoft SQL Server
installed in order to use SQLCMD.
As an alternative to installing Microsoft SQL Server, you can install the
free Microsoft SQL Server Feature Pack. You can download and install
the latest version of the Microsoft SQL Server Feature Pack by using
your favorite search engine to find it by name, or you can use the following link for the Microsoft SQL Server 2008 R2 SP1 Feature Pack:
Deploying to Windows Azure
If you’d like to avoid hosting your own website and take advantage of the increasing
amount of “cloud capacity” available to you, one other deployment and hosting option
is Microsoft’s cloud hosting platform, Windows Azure. With Windows Azure, you can
concentrate on your application and let Microsoft worry about the infrastructure required to host it on the Internet.
The rest of this section will walk you through the simple steps for deploying your
application to the cloud using Windows Azure. When you’re finished, you will have a
public website hosted in the cloud.
Deploying to Windows Azure | 407