Home/Web Forms/Tutorials/Chapter 9. Deployment/Deployment to a Hosting Provider/Visual Studio Web Deployment - Deploying to the Production Environment

Overview

Now that you have deployed to IIS and tested there, you are ready to make the application available to the public. In this tutorial you will set up an account with a hosting provider and deploy your application to the production environment.

Reminder: If you get an error message or something doesn't work as you go through the tutorial, be sure to check the troubleshooting page.

Selecting a Hosting Provider

For the Contoso University application and this tutorial series, you need a provider that supports ASP.NET 4 and Web Deploy. A specific hosting company was chosen so that the tutorials could illustrate the complete experience of deploying to a live website. Each hosting company provides different features and the experience of deploying to their servers varies somewhat; however, the process described in this tutorial is typical for the overall process. The hosting provider used for this tutorial, Cytanium.com, is one of many that are available, and its use in this tutorial does not constitute an endorsement or recommendation.

When you are ready to select your own hosting provider, you can compare features and prices using the gallery of providers on the Microsoft.com/web site.

Creating an Account

Create an account at your selected provider. If support for a full SQL Server database is an added extra, you do not need to select it for this tutorial, but you will need it for later tutorials in the series that show how to migrate to full SQL Server.

For these tutorials you don't need to register a new domain name. You can select the option to use an existing domain name, enter whatever name you want, and test to verify successful deployment using the temporary URL assigned to the site by the provider.

After the account has been created, you typically receive a welcome email that contains all the information you need to deploy and manage your site. Again, the specifics of the information that your hosting provider sends you might be slightly different, but will be similar to those shown here. The Cytanium welcome email that's sent to new account owners includes the following information:

• The URL to the provider's control panel site, where you can manage settings for your site. The ID and password you specified are included in this part of the welcome email for easy reference (both have been changed to a demo value for this illustration).

  

• The default .NET Framework version and information about how to change it. Many hosting sites default to 2.0, which works with ASP.NET applications that target the .NET Framework 2.0, 3.0, or 3.5. However Contoso University is a .NET Framework 4 application, so you will need to change this setting later.

  

• The temporary URL that you can use to access your web site. When this account was created, "contosouniversity.com" was entered as the existing domain name. Therefore the temporary URL is http://contosouniversity.com.vserver01.cytanium.com.

  

• Information about how to set up databases, and the connection strings that you need to access them:

  

• Information about tools and settings for deploying your site. (The email from Cytanium also mentions WebMatrix, which is omitted here.)

  

Setting the .NET Framework Version

The Cytanium welcome email includes a link to instructions on how to change the version of the .NET Framework. These instructions explain that this can be done through the Cytanium control panel. Other providers have control panel sites that look different, or they may instruct you to do this in a different way.

Go to the control panel URL. After logging in with your user name and password, you see the control panel.

In the Hosting Spaces box, hold the pointer over the Web icon and select Web Sites from the menu.

In the Web Sites box, click contosouniversity.com (the name of the site that you used when you created the account).

In the Web Site Properties box, select the Extensions tab.

Change ASP.NET from 2.0 Integrated Pipeline to 4.0 (Integrated Pipeline), and then click Update.

Publishing to the Hosting Provider

Change the active build configuration to Release. You can use the toolbar, as shown below, or select Configuration Manager from the Build menu.

In Solution Explorer, right-click the ContosoUniversity project and select Publish. The Publish Web dialog box appears with the Test profile selected because that is all you have created so far.

In the Publish profile box, select new.

Enter "Production" for the new profile name.

Enter the Service URL value that the hosting provider sent you in the welcome email.

Enter the Site/application value that the hosting provider sent you in the welcome email.

Select Mark as IIS application on destination.

Make sure that Leave extra files on destination (do not delete) is selected. If you clear this checkbox, Web Deploy will delete any files from the destination site that it does not find in the source site. For the initial deployment this will have no effect because there are not yet any files in the destination site to be deleted, but in subsequent update deployments, selecting this option could have unintended results. For example, any log files in the Elmah folder in production would be deleted because identical files would not exist in your Visual Studio project.

Select Allow untrusted certificate.

Enter the credentials provided to you by the hosting provider.

Select Save password so that you don't have to enter the password every time you publish.

Click Publish.

The application is published to the hosting provider, and the result shows in the Output window.

Setting Folder Permissions for Elmah

As you remember from the previous tutorial in this series, you must make sure that the application has Write permissions for the folder in your application where Elmah error log files are stored as XML files. When you deployed to IIS locally on your computer, you set those permissions manually. In this section, you'll see how to set permissions at Cytanium. (Some hosting providers may not enable you to do this; they may offer one or more predefined folders with Write permissions, in which case you would have to modify your application to use the specified folders.)

You can set folder permissions in the Cytanium control panel. Go to the control panel URL and select File Manager.

In the File Manager box, select contosouniversity.com and then wwwrooot to see the application's root folder. Click the padlock icon next to Elmah.

In the File/Folder Permissions window, select the Read and Write checkboxes for contosouniversity.com and click Set Permissions.

Testing in the Production Environment

Open a browser and go to the temporary URL that the provider specified when you created the account. (For this example, the URL is http://contosouniversity.com.vserver01.cytanium.com) You see the same home page as when you run the site in Visual Studio, except now there is no "(Test)" or "(Dev)" environment indicator in the title bar, which indicates that the environment indicator Web.config transformation worked correctly.

Run the Students page to verify that the deployed database has no students:

Run the Instructors page to verify that other data is still in the database:

As you did in the test environment, you want to verify that database updates work in the production environment, but you typically do not want to enter test data into your production database. For this tutorial you'll use the same method you did in test. But in a real application you might want to find a different method, something you can do to validate that database updates are successful but without introducing test data into the production database. In some applications, it might be practical to add something and then delete it.

Add a student and then view the data you entered in the Students page to verify that database update functionality works:

Validate that authorization rules are working correctly by selecting Update Credits from the Courses menu. The Log In page is displayed. Enter your administrator account credentials, click Log In, and the Update Credits page is displayed.

If login is successful, the Update Credits page is displayed. This indicates that the ASP.NET membership database (with the single administrator account) was successfully deployed.

Make sure that Elmah has write access to the Elmah folder by causing an error and then displaying the Elmah error report. Request an invalid URL like Studentsxxx.aspx. As before, you see the GenericErrorPage.aspx page. Click the Log Out link, and then run Elmah.axd. You get the Log In page first, which validates that the Web.config transform successfully added Elmah authorization. After you log in, you see the report showing the error you just caused.

You have now successfully deployed and tested your site and it is available publicly over the internet.

Creating a More Reliable Test Environment

As explained in the Deploying to the Test Environment tutorial, the most reliable test environment would be a second account at the hosting provider that's just like the production account. This would be more expensive than using local IIS as your test environment, since you would have to sign up for a second hosting account. But if it prevents production site errors or outages, you might decide that it's worth the cost.

Most of the process for creating and deploying to a test account is similar to what you've already done to deploy to production:

• Create a new build configuration and Web.config transformation file as you did in the Web.config File Transformations and Configuring Project Properties tutorials.
• Create an account at the hosting provider and set up for deployment using the new build configuration, as you did using the production build configuration in this tutorial.
• Create a new publish profile and deploy to the test account.

Preventing Public Access to the Test Site

An important consideration for the test account is that it will be live on the Internet, but you don't want the public to use it. To keep the site private, you can do this:

• Contact the hosting provider to set firewall rules that allow access to the testing site only from IP addresses that you use for testing.
• Disguise the URL so that it is not similar to the public site's URL.
• Use a robots.txt file to ensure that search engines will not crawl the test site and report links to it in search results.

The first of these is obviously the most secure, but the procedure for that is specific to each hosting provider and will not be covered in this tutorial. If you do arrange with your hosting provider to allow only your IP address to browse to the test account URL, you theoretically don't need to worry about search engines crawling it. But even in that case, deploying a robots.txt file is a good idea as a backup in case that firewall rule is ever accidentally turned off.

The robots.txt file goes in your project folder and should have the following text in it:

User-agent: *
Disallow: /

The User-agent line tells search engines that the rules in the file apply to all search engine web crawlers (robots), and the Disallow line specifies that no pages on the site should be crawled.

You probably do want search engines to catalog your production site, so you need to exclude this file from production deployment. To do that, see "Can I exclude specific files or folders from deployment?" in ASP.NET Web Application Project Deployment FAQ. Make sure you specify the exclusion only for the Release build configuration.

Creating a second hosting account is an approach to working with a test environment that is not absolutely required but might be worth the added expense. In the following tutorials you'll continue to use IIS as your test environment.

In the next tutorial, you'll make a change to the application and deploy your change to the test and production environments.

1. ← PreviousVisual Studio Web Deployment - Setting Folder Permissions
2.  You're ViewingVisual Studio Web Deployment - Deploying to the Production Environment
3. → NextVisual Studio Web Deployment - Deploying a Code-Only Update