How do you deploy your ASP.NET applications to live servers?

Viewed 37594

I am looking for different techniques/tools you use to deploy an ASP.NET web application project (NOT ASP.NET web site) to production?

I am particularly interested of the workflow happening between the time your Continuous Integration Build server drops the binaries at some location and the time the first user request hits these binaries.

  1. Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)?

  2. When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?

  3. When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?

  4. Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?

Feel free to complete the previous list.


And here's what we use to deploy our ASP.NET applications:

  1. We add a Web Deployment Project to the solution and set it up to build the ASP.NET web application
  2. We add a Setup Project (NOT Web Setup Project) to the solution and set it to take the output of the Web Deployment Project
  3. We add a custom install action and in the OnInstall event we run a custom build .NET assembly that creates an App Pool and a Virtual Directory in IIS using System.DirectoryServices.DirectoryEntry (This task is performed only the first time an application is deployed). We support multiple Web Sites in IIS, Authentication for Virtual Directories and setting identities for App Pools.
  4. We add a custom task in TFS to build the Setup Project (TFS does not support Setup Projects so we had to use devenv.exe to build the MSI)
  5. The MSI is installed on the live server (if there's a previous version of the MSI it is first uninstalled)
13 Answers

We have all of our code deployed in MSIs using Setup Factory. If something has to change we redeploy the entire solution. This sounds like overkill for a css file, but it absolutely keeps all environments in sync, and we know exactly what is in production (we deploy to all test and uat environments the same way).

We do rolling deployment to the live servers, so we don't use installer projects; we have something more like CI:

  • "live" build-server builds from the approved source (not the "HEAD" of the repo)
  • (after it has taken a backup ;-p)
  • robocopy publishes to a staging server ("live", but not in the F5 cluster)
  • final validation done on the staging server, often with "hosts" hacks to emulate the entire thing as closely as possible
  • robocopy /L is used automatically to distribute a list of the changes in the next "push", to alert of any goofs
  • as part of a scheduled process, the cluster is cycled, deploying to the nodes in the cluster via robocopy (while they are out of the cluster)

robocopy automatically ensures that only changes are deployed.

Re the App Pool etc; I would love this to be automated (see this question), but at the moment it is manual. I really want to change that, though.

(it probably helps that we have our own data-centre and server-farm "on-site", so we don't have to cross many hurdles)

Website

Deployer: http://www.codeproject.com/KB/install/deployer.aspx

I publish website to a local folder, zip it, then upload it over FTP. Deployer on server then extracts zip, replaces config values (in Web.Config and other files), and that's it.

Of course for first run you need to connect to the server and setup IIS WebSite, database, but after that publishing updates is piece of cake.

Database

For keeping databases in sync I use http://www.red-gate.com/products/sql-development/sql-compare/

If server is behind bunch of routers and you can't directly connect (which is requirement of SQL Compare), use https://secure.logmein.com/products/hamachi2/ to create VPN.

Simple XCopy for ASP.NET. Zip it up, sftp to the server, extract into the right location. For the first deployment, manual set up of IIS

Answering your questions:

  1. XCopy
  2. Manually
  3. For static resources, we only deploy the changed resource.
    For DLL's we deploy the changed DLL and ASPX pages.
  4. Yes, and yes.

Keeping it nice and simple has saved us alot of headaches so far.

web setup/install projects - so you can easily uninstall it if something goes wrong

Back in 2009, where this answer hails from, we used CruiseControl.net for our Continuous Integration builds, which also outputted Release Media.

From there we used Smart Sync software to compare against a production server that was out of the load balanced pool, and moved the changes up.

Finally, after validating the release, we ran a DOS script that primarily used RoboCopy to sync the code over to the live servers, stopping/starting IIS as it went.

Related