Web Deployment Overview for Visual Studio and ASP.NET

This topic provides an overview of the tasks that are required to publish (deploy) a Visual Studio web project to a server where others can access the application over the Internet.

The topic contains the following sections:

• Typical Deployment Scenarios

• Basic Deployment Tasks

• Configuring Database Deployment in Visual Studio

• Other Deployment Tasks

• Backup and Restore

Typical Deployment Scenarios

You can deploy a web project by using one-click publish or a deployment package:

• One-click publish refers to a feature in Visual Studio that lets you deploy directly from the Visual Studio IDE by clicking a button. Visual Studio connects to a destination server, copies project files to it, and performs other deployment tasks.

• A web deployment package is a .zip file that contains all the information needed for deployment. You create the package from the command line or in Visual Studio, and you install it on the destination server by using the command line or IIS Manager.

Which of these methods you use depends on your scenario and your personal preference. One-click publish is typically the best choice for smaller organizations that do not implement a continuous integration (CI) development process. You would typically deploy to a hosting company where your application runs either in a shared hosting environment or on a dedicated server. (In a shared hosting environment, a single server is used to host sites for multiple hosting company clients.)

In an enterprise environment, you typically deploy to your own company's servers, which are in turn connected to the Internet, and you typically implement a CI process. The application is promoted through testing and staging environments before it is deployed to production. In these scenarios you can use one-click publish to deploy to a testing environment, but for the progression through different environments to production, a deployment package would typically be used. Deployment packages are more appropriate for enterprise scenarios because they can be integrated into the CI process by using the command line to create and install the packages.

Both the third-party hosting and enterprise scenarios apply also when you host your web application in the cloud by using Windows Azure. In Windows Azure, your application can run in a shared hosting environment or on dedicated virtual machines.

Basic Deployment Tasks

Here are the basic tasks that you have to do in order to deploy to a third-party hosting company:

1. Set up an account with a hosting company.

   For information about hosting providers that support automated deployment from Visual Studio, see ASP.NET Hosting. Make sure that you choose a provider that supports the version of ASP.NET that your web project targets.

2. Create a publish profile.

   A publish profile specifies the server you are deploying to, credentials for logging on to the server, databases to deploy, and other options. The hosting company sends you the settings you need for the publish profile, either in an email or in a file that you can import into Visual Studio.

3. Start the deployment process by clicking the one-click publish button.

   The Publish button is in the Publish Web wizard that you use to create publish profiles. It is also available in the Web One Click Publish toolbar that you can choose from the View–Toolbars menu in Visual Studio.

For general help with this process, see How to: Deploy a Web Project Using One-Click Publish in Visual Studio. For a 12-part tutorial that guides you through an end-to-end scenario for deployment from Visual Studio, see Deployment to a Hosting Provider on the ASP.NET site.

The preceding procedure describes how to use the Microsoft Web Deploy or FTP publish methods with the one-click publish feature to deploy a web project. An alternative is to use the File System publish method and then use your own FTP tool to transfer the files to the hosting provider.

For enterprise deployment scenarios, see the Deploying Web Applications in Enterprise Scenarios tutorial series on the ASP.NET site. The enterprise deployment tutorials were written for Visual Studio 2010 and have not yet been updated for Visual Studio 2012.

Configuring Database Deployment in Visual Studio

Visual Studio offers three methods of automated database deployment:

1. Entity Framework Code First Migrations

2. The dbDacFx Web Deploy Provider

3. The dbFullSql Web Deploy Provider

All three methods require the Web Deploy publish method. If you use a different publish method, such as FTP, File System, or FPSE, you have to handle database deployment outside of Visual Studio. For more information, see Deploying a database separately from web application deployment.

Entity Framework Code First Migrations

In the Entity Framework version 4.3, Microsoft introduced Code First Migrations. Code First Migrations automates the process of making incremental changes to a data model and propagating those changes to the database. In earlier versions of Code First, you typically let the Entity Framework drop and re-create the database each time you changed the data model. This is not a problem in development because test data is easily re-created, but in production you usually want to update the database schema without dropping the database. The Migrations feature enables Code First to update the database without dropping and re-creating it. You can let Code First automatically decide how to make the required schema changes, or you can write code that customizes the changes. For an introduction to Code First Migrations, see Code First Migrations.

If you are deploying a web application project, Visual Studio can automate the process of deploying a database that is managed by Code First Migrations. When you configure the publish profile, you select a check box that is labeled Execute Code First Migrations (runs on application start):

This check box is shown for databases that the application accesses by using an Entity Framework Code First context class. When you select this option, the deployment process automatically configures the application Web.config file on the destination server so that Code First uses the MigrateDatabaseToLatestVersion initializer class. The following illustration shows an example of what this setting looks like in the Web.config file:

The Execute Code First Migrations option also causes the deployment process to put an additional connection string in the destination Web.config file:

Code First uses this additional connection string for making the database schema changes. This connection string must specify user credentials that have administrative access to the database. Because Code First uses a separate connection string for schema updates, you can specify user credentials that have limited permissions in the application connection string. For more information, see Reviewing the Automatic Web.config Changes for Code First Migrations on the ASP.NET site.

Visual Studio does not do anything with the database during the deployment process. When the deployed application accesses the database for the first time after deployment, Code First automatically creates the database or updates the database schema to the latest version. If the application implements a Migrations Seed method, the method runs after the database is created or the schema is updated.

For information about how to configure Code First Migrations deployment in Visual Studio, see How to: Deploy a Web Project Using One-Click Publish in Visual Studio and the tutorial series Deploying an ASP.NET Web Application to a Hosting Provider using Visual Studio or Visual Web Developer.

The dbDacFx Web Deploy Provider

In order to use the dbDacFx Web Deploy provider for database deployment, you select the check box labeled Update database in the Publish Web wizard. This check box is shown for SQL Server databases that the application accesses without using an Entity Framework Code First context class:

During the initial deployment, the dbDacFx provider creates tables and other database objects in the destination database to match the source database. On subsequent deployments, the provider determines what is different between the source and destination databases, and it updates the schema of the destination database to match the source database. By default, the provider won't make any changes that cause data loss, such as when a table or column is dropped.

This option also lets you specify your own custom SQL scripts that you want to run in the destination database during deployment. For example, you could run custom scripts in order to insert initial data into tables after the provider creates the tables. Or you could run custom scripts in order to make schema changes that can't be done automatically because they would cause data loss.

This database deployment method requires that Web Deploy 3.0 and the dbDacFx provider be installed on the destination web server. (They do not have to be installed on the destination database server.)

The dbDacFx provider does not work with operating systems earlier than Windows Vista SP2, such as Windows XP and Windows Server 2003. For database deployment on those operating systems, use the dbFullSql Web Deploy Provider.

For information about how to deploy a database by using the dbDacFx provider, and how to install Web Deploy 3.0 and the dbDacFx provider on a destination web server, see How to: Deploy a Web Project Using One-Click Publish in Visual Studio.

The dbFullSql Web Deploy Provider

In order to use the dbFullSql Web Deploy provider, you configure database deployment settings on the Package/Publish SQL tab of the project properties window. This database deployment method has been available since Visual Studio 2010 SP1. The dbFullSql provider can do the initial deployment of the database schema, and it can optionally deploy data as well as schema. This provider does not do incremental database deployment. If you try to use this provider to deploy schema updates to an existing database, deployment fails because the provider tries to create tables that already exist.

The dbFullSql provider is a legacy database deployment method that should be used only when needed for specific scenarios, such as when you are using the Windows XP or Windows Server 2003 operating system. For information about how to configure database deployment that uses the dbFullSql provider, see Package/Publish SQL Tab, Project Properties and Migrating to SQL Server on the ASP.NET site.

Other Deployment Tasks

Depending on your scenario or features of your application, other deployment tasks may be required or advisable. Here is a list of some of the more common ones:

• Configure Web.config transformations.

  Your application's Web.config file might contain settings that have to be different in the deployed application. For example, you typically enable debugging during development and disable it in production. For web application projects, the project template automatically creates a transformation file that disables debugging in production. For web site projects, we recommend that you create a transformation file that disables debugging for each publish profile that you use to deploy to production.

  For more information, see Web.config File Transformations on the ASP.NET site and Web.config Transformation Syntax for Web Project Deployment Using Visual Studio.

  If you are deploying to a Windows Azure Web Site, and if you want to transform settings in the appSettings or connectionStrings elements, an alternative is to store the values for the destination site in Windows Azure. For more information, see Windows Azure Web Sites: How Application Strings and Connection Strings Work on the Windows Azure blog.

• Specify which files and folders should be copied to the destination server.

  By default, Visual Studio deploys only the files that are needed to run the application. This option works well for most scenarios, but you might have special requirements. For example, you might want to exclude database files in the App_Data folder if those files are only used in development. For more information, see Configuring Project Properties on the ASP.NET site and Package/Publish Web Tab, Project Properties.

• Set folder permissions on the destination server.

  Your application might need write permissions to some of your project folders. For example, if the application lets users upload files, it needs write access to the folder where it saves the uploaded files. You typically have to explicitly configure these permissions as part of the deployment process or after the application has been deployed. For more information, see Setting Folder Permissions on the ASP.NET web site.

• Precompile the project.

  By default, web site projects are not precompiled, and .aspx and .ascx pages are not precompiled in web application projects. In some large applications, the process of compiling can result in a slight delay that might be noticeable the first time a web page is requested after deployment. For information about web project compile and merge options and how to specify them, see How to: Deploy a Web Project Using One-Click Publish in Visual Studio.

• Take the application off-line during deployment.

  You might not want users to be able to use the application while it is being deployed. This is often the case when you deploy database updates, since there might be a risk of running application code that is out of sync with the database. For more information, see Making sure an application is off-line during deployment.

• Test the site in an environment similar to production before deploying it to production.

  To reduce the chance of finding bugs only after you've deployed to production, you typically test the application in an environment that's as similar to the production environment as possible. To do this, before you deploy to the production server, you can deploy to IIS on your development computer, to a staging server, or to a test account at your hosting provider. For more information, see Deploying to IIS as a Test Environment on the ASP.NET site.

• Configure deployment settings that aren't exposed in the Visual Studio UI.

  The Visual Studio UI does not expose all of the deployment settings that you can configure. For example, you can't use the UI to exclude an individual folder from deployment. However, you can do this by editing the files that store configuration settings. For each publish profile there is a .pubxml file that you can edit directly. If you want to configure deployment settings that apply to all publish profiles, you can create a .wpp.targets file. For more information, see How to: Edit Deployment Settings in Publish Profile (.pubxml) Files and the .wpp.targets File in Visual Studio Web Projects.

• Make sure that binary files for ASP.NET MVC are copied to the server.

  If you're deploying to a hosting provider that does not support ASP.NET MVC or your target version of it, make sure that you have installed the appropriate MVC 3 or MVC 4 NuGet package in your project.

• Make sure that binary files for SQL Server Compact 4.0 are copied to the server.

  If you're deploying to a hosting provider that does not support SQL Server Compact 4.0, make sure that you have installed the SqlServerCompact NuGet package in your project. You must also include the bin\x86 and bin\amd64 folders in your project. For more information, see Deploying SQL Server Compact Databases.

• Make sure that the destination server can correctly generate password hashes or decrypt encrypted information in a database.

  For example, the ASP.NET membership database stores a hash of account passwords. In order to deploy accounts from one machine to another, you must make sure that hashing routines don't generate different hashes on the destination server than they do on the source computer. They will generate the same hashes when you use the ASP.NET Universal Providers, as long as you don't change the default algorithm. The default algorithm is HMACSHA256 and is specified in the validation attribute of the machineKey element in the Web.config file.

• Install certificates on the server.

  Certificates might have to be installed on the server if you your application uses SSL or Windows Identity Foundation.

Backup and Restore

Before you deploy an update to an existing site, create a rollback plan so that you are able to restore the application to its original state if anything goes wrong. Some things to think about include the following:

• Back up all of the code and resources used by the site.

  Warning

  Do not assume that by deploying to a server you are creating a backup of your project. Source code that is compiled into assemblies before deployment is typically not copied to the server.

• If the update includes database changes, create a rollback plan for backing out the database changes. You might want to create rollback scripts in advance just in case. You might also want to think about what to do if any data was entered into changed tables after the deployment but before the rollback, or if other applications use the same database.

• If the application interfaces with other applications, create a rollback plan that specifies what to do about them if you have to roll back an update.

See Also

Other Resources

Web Deployment Content Map for Visual Studio and ASP.NET