Tải bản đầy đủ - 0 (trang)
“bin-deploying” ASP.NET MVC libraries

“bin-deploying” ASP.NET MVC libraries

Tải bản đầy đủ - 0trang

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

Static content can refer to any type of file, but the majority of these files will almost

always be the JavaScript files, CSS stylesheets, and images that provide your application’s client-side logic and styling. Although these files can technically live anywhere

in your site’s folder structure, the default ASP.NET MVC project templates create

the /Scripts, /Images, and /Content folders for you to place all of your JavaScript files

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

Figure 19-5).

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

reference application:

• 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

everything else

• 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

begin deploying!

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


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

“bin-deploying” ASP.NET MVC libraries

Tải bản đầy đủ ngay(0 tr)