VS2010 ASP.NET Deployment

Question

How do I deploy to a shared hosting environment... code and database (full blown SQL).

What is your favorite way to get a 50MB single project ASP.NET Web Application Project and database to a live server with FTP and SQL Management Studio ports accessible?

After a day of exploration mine is: - Use the Web.Debug.config to easily allow the different connection strings, smtp etc

• setup Package/Publish SQL in properties of the Project to have source database information.

• change the .csproj to allow DROP statements ScriptDropsFirst="True" from http://vishaljoshi.blogspot.com/2009/08/replacing-your-old-db-with-new-one.html

• deploy to a filesystem c:\deploy and use FileZilla to copy to my FTP site (with overwrite only if source is newer)

• Use SQL Management Studio to take the .SQL script from \obj\Release\AutoScripts

Answer 1

FileZilla deployment is OK as long as you don't mind the brief downtime this may cause. While you're deploying, the site can be in an inconsistent state (e.g. you've deployed a .aspx file which references code-behind in a DLL that isn't there yet). So visitors to the site during this time can run into errors - if you don't catch these errors, they'll see the "yellow screen of death". This will clear up once all the files are deployed.

Here's a process that's worked for me in the past, for minimal-downtime deployment to a single server:

1. On the production server, copy all code from the live location (e.g. c:\Sites\MySite) to a backup location (e.g. c:\Sites\MySite_bak)
2. Change the site's virtual root from c:\Sites\MySite to c:\Sites\MySite_bak. This will cause some delays for site visitors, since ASP.NET needs to re-JIT the ASPX pages; but visitors won't see errors.
3. Use FileZilla to deploy to c:\Sites\MySite, with "overwrite if source is newer"
4. Change the site's virtual root from c:\Sites\MySite_bak back to c:\Sites\MySite. This will atomically switch the site to the new version. There'll be another JIT delay.
5. Keep the backup version around on the live server in case you ever need to revert your changes.

If you're also making DB schema changes, you'd want to do that at the same time as (4). Or if the changes are compatible with the old version of the code, you could do them sooner.

I've been assuming you only have the one server. If you have a server farm, you can do rolling deployments by taking one server at a time out of the load-balancing pool.