Chapter 12: Deploying the Site

You've come to the end of the development: Your site is ready, you've tested it locally and it all works fine, and now you have to publish it online. If you've ever had any experience with older legacy ASP/COM applications, and later with ASP.NET 1.x applications, you already know that .NET made deployment much easier: You no longer had any COM components to register, or shared components that might overwrite an existing version and thus break other applications. For pure ASP.NET applications it may suffice to do an XCOPY of all your deployment-related files (such as .aspx, .dll, .config, and image files) to the remote server, and then deploy the database. However, in the real world, things usually tend to get a little more complex than that because you have constraints and company policies to respect regarding the deployment of your application. Database deployment and configuration are also nontrivial, and you should consider this carefully before you start rolling out the site. In this final chapter, I will guide you through all of the different options to successfully deploy your web site's files and the database, explaining why and when some techniques are more suitable than another.

Problem

The problem described and solved here was a real problem that I faced while completing the sample site. I wanted to put the site online somewhere so that potential readers could browse it and consider whether it was worth the purchase, and so that I could show it to clients and colleagues during presentations about ASP.NET 2.0.

Not having a private dedicated server connected to the Internet available for this project, I chose to deploy the site to a typical shared web hosting service that uses servers running Windows Server 2003 and supports ASP.NET 2.0 and SQL Server 2005. Most of these Microsoft-centric web hosting companies now support this platform, and several of them offer plans that cost as little as $10 per month. When evaluating hosting service companies, you need to ensure that they offer you enough disk space and bandwidth, and that you factor in the cost of SQL Server 2005 (some companies charge extra for this). Of course, your specific hosting requirements may vary according to the type of project you're working on. For high-usage sites, or large-size sites, or just sites that require high availability, you'll want dedicated servers configured as a web farm (whereby a number of servers are running the same applications and load-balancing is used to determine which server will process a specific web request). Also consider that our sample web site is 100% pure ASP.NET 2.0, with no legacy COM components, COM+ services, or Windows services: These things would require special installation and are usually not allowed by basic low-cost hosting plans. In our case we don't need the benefits of a dedicated server or web farm, so a shared hosting plan is fine. For the situation just described, the problem statements are pretty simple to formulate:

What files do I need to deploy?
How do I deploy those files?
How can I protect my source code against prying eyes, once the web site has been published on a shared remote server?
How do I move my local SQL Server Express database into a full SQL Server 2005 database (when SQL Server Express has been used to develop the site)?
How do I create an installer that automates the whole site's setup, which would be useful if I sold the web site as a product, or if I wish to deploy to a dedicated web server?

In the following pages you'll find answers for all of these questions.