ASP.NET Website Programming: Problem - Design - Solution : Deploying the Site

Now that we have developed our website, we need to deploy it – prepare and distribute the site so that users can access it.

The release of ASP.NET forces us to reconsider many preconceptions about the deployment of websites. For example, we need to get used to the possibility of running multiple copies of the same site on a single server, sharing different versions of identically named DLLs. Another thing that developers might find incredible is XCopy deployment, which allows a developer to deploy an application by simply copying files to the target location. There's no need to use the Registry or any complex COM registration.

In the past, deploying a large-scale web application could become a nightmare. Most enterprise web sites were comprised of dozens (or more) COM and COM+/MTS components. Maintaining the information on all of those components in the Registry and making sure that the information was updated properly when upgrading to a new version was an incredibly difficult task. ASP.NET allows entire websites to be configured with simple XML text files, and components to automatically register themselves in COM+. There's no need to look to the registry for anything in deployment of ASP.NET, completely alleviating one of the biggest ASP deployment headaches.

This chapter will discuss the general issues surrounding the deployment of ASP.NET websites and the various approaches we can take. We will describe the deployment techniques we used for ThePhile.com.

The Problem
Our problem for this chapter is deploying our fully functional website to our production server.

It is a common practice to develop a site on a development server, then deploy to a staging server, and finally after a successful test on the staging server, deploy to the production server. We want a solution that will allow us to deploy the entire functioning site to a production server. However, we also want to be able to easily deploy the code to multiple machines so that we can test it in various scenarios. In our solution, our production server is hosted by Wrox, but it could just as easily be a segment of disk space allocated to us by a website hosting company.

So, in this chapter we want to explore the various ways we can deploy ASP.NET websites and then choose the one that best suits our needs. The chapter will provide some useful information about ASP.NET deployment that will help decide which method is most appropriate for different organizations.

The Design
There are two parts to deploying the website: the database and the application. First of all, we will discuss how to deploy the database. Then we will move on to look at the web application itself.

Deploying the Data Store
A data store for a website can be anything from a set of XML files or simple Access database, to a complex SQL Server or Oracle database. Each of the website deployment options has a different set of limitations and advantages for database deployment. However, since database deployment is an important topic all on its own, we'll discuss it here rather than split up the discussion among the different installation scenarios.

Deploying a database is easiest when we own the machine to which it needs to be deployed. We can use whatever deployment scenario is most convenient for copying our particular data store. For SQL Server or Oracle there are several options, including:

• Making a backup of the development database and restoring from that backup on another machine.
• Transferring data structures and data between linked servers in some fashion, perhaps using script files.

We often don't fully control the database server. Web hosting companies often set up a single database with a certain quota of disk space, for example. In situations like this, our options are more limited. We probably can't restore from a backup, because we won't have access to Enterprise Manager against the host's database servers. Even if we do have access to Enterprise Manager, we might not have the right permissions to perform a database restore. In these cases, we are limited to using text queries to create the data structures and load the data.

For an Access database, the file just needs to be copied to a certain directory and the file is deployed. It doesn't matter what server access we have. This does pose a serious danger: if an unwanted intruder happens to find out that your Access database is available in a public internet directory, they'll be able to download it. You'll want to keep the MDB file somewhere non-obvious and preferably in a private location, so that only code from your application can access the file.

For automated deployment, where we create an installation program for our website, we have another option. We can take the scripts that recreate the data structures required for the application, and can have our installer execute them at instal<ime, guaranteeing that the data structures will be available before the application is run for the first time.

Preparing the Site for Deployment
There are three main scenarios that we will consider for deploying our ASP.NET website:

• XCopy deployment
• A specialized type of XCopy deployment for deploying a website to a hosted server that we have little control over
• Using Visual Studio .NET to create an installation program that will perform the installation and deployment process automatically

While there are a great number of variations in the ways to deploy an ASP.NET website, all of them will derive from a combination of the above three. We will discuss each of these methods in detail and explain the benefits and drawbacks of each, and then apply that information to our situation in terms of deploying ThePhile.com.

The following diagram shows a sample website directory structure. It includes a list of some DLLs that the sample application might be using. The directory structure contains everything that is required to run the application, except the database. There are no Registry entries to be made:

A sample website directory structure

During development, the folder structure will not be this neat. In fact, things can get downright messy. In ThePhile's development folder, we have many copies of the same DLL and source code for all classes, even supposedly secret business and data layer classes. Deploying all this would waste our disk space and pose a security risk. We should only deploy the files required to execute the application – one copy of each DLL, and only source code for classes that compile on the fly.

Now that we have developed our website, we need to deploy it – prepare and distribute the site so that users can access it.

The release of ASP.NET forces us to reconsider many preconceptions about the deployment of websites. For example, we need to get used to the possibility of running multiple copies of the same site on a single server, sharing different versions of identically named DLLs. Another thing that developers might find incredible is XCopy deployment, which allows a developer to deploy an application by simply copying files to the target location. There's no need to use the Registry or any complex COM registration.

In the past, deploying a large-scale web application could become a nightmare. Most enterprise web sites were comprised of dozens (or more) COM and COM+/MTS components. Maintaining the information on all of those components in the Registry and making sure that the information was updated properly when upgrading to a new version was an incredibly difficult task. ASP.NET allows entire websites to be configured with simple XML text files, and components to automatically register themselves in COM+. There's no need to look to the registry for anything in deployment of ASP.NET, completely alleviating one of the biggest ASP deployment headaches.

This chapter will discuss the general issues surrounding the deployment of ASP.NET websites and the various approaches we can take. We will describe the deployment techniques we used for ThePhile.com.

The Problem
Our problem for this chapter is deploying our fully functional website to our production server.

It is a common practice to develop a site on a development server, then deploy to a staging server, and finally after a successful test on the staging server, deploy to the production server. We want a solution that will allow us to deploy the entire functioning site to a production server. However, we also want to be able to easily deploy the code to multiple machines so that we can test it in various scenarios. In our solution, our production server is hosted by Wrox, but it could just as easily be a segment of disk space allocated to us by a website hosting company.

So, in this chapter we want to explore the various ways we can deploy ASP.NET websites and then choose the one that best suits our needs. The chapter will provide some useful information about ASP.NET deployment that will help decide which method is most appropriate for different organizations.

The Design
There are two parts to deploying the website: the database and the application. First of all, we will discuss how to deploy the database. Then we will move on to look at the web application itself.

Deploying the Data Store
A data store for a website can be anything from a set of XML files or simple Access database, to a complex SQL Server or Oracle database. Each of the website deployment options has a different set of limitations and advantages for database deployment. However, since database deployment is an important topic all on its own, we'll discuss it here rather than split up the discussion among the different installation scenarios.

Deploying a database is easiest when we own the machine to which it needs to be deployed. We can use whatever deployment scenario is most convenient for copying our particular data store. For SQL Server or Oracle there are several options, including:

• Making a backup of the development database and restoring from that backup on another machine.
• Transferring data structures and data between linked servers in some fashion, perhaps using script files.

We often don't fully control the database server. Web hosting companies often set up a single database with a certain quota of disk space, for example. In situations like this, our options are more limited. We probably can't restore from a backup, because we won't have access to Enterprise Manager against the host's database servers. Even if we do have access to Enterprise Manager, we might not have the right permissions to perform a database restore. In these cases, we are limited to using text queries to create the data structures and load the data.

For an Access database, the file just needs to be copied to a certain directory and the file is deployed. It doesn't matter what server access we have. This does pose a serious danger: if an unwanted intruder happens to find out that your Access database is available in a public internet directory, they'll be able to download it. You'll want to keep the MDB file somewhere non-obvious and preferably in a private location, so that only code from your application can access the file.

Note: Consult your SQL Server, Oracle, or Access manual for the various options available for transferring your database from your development PC to a deployed production environment.

For automated deployment, where we create an installation program for our website, we have another option. We can take the scripts that recreate the data structures required for the application, and can have our installer execute them at instal<ime, guaranteeing that the data structures will be available before the application is run for the first time.

Preparing the Site for Deployment
There are three main scenarios that we will consider for deploying our ASP.NET website:

• XCopy deployment
• A specialized type of XCopy deployment for deploying a website to a hosted server that we have little control over
• Using Visual Studio .NET to create an installation program that will perform the installation and deployment process automatically

While there are a great number of variations in the ways to deploy an ASP.NET website, all of them will derive from a combination of the above three. We will discuss each of these methods in detail and explain the benefits and drawbacks of each, and then apply that information to our situation in terms of deploying ThePhile.com.

The following diagram shows a sample website directory structure. It includes a list of some DLLs that the sample application might be using. The directory structure contains everything that is required to run the application, except the database. There are no Registry entries to be made:

A sample website directory structure

During development, the folder structure will not be this neat. In fact, things can get downright messy. In ThePhile's development folder, we have many copies of the same DLL and source code for all classes, even supposedly secret business and data layer classes. Deploying all this would waste our disk space and pose a security risk. We should only deploy the files required to execute the application – one copy of each DLL, and only source code for classes that compile on the fly.