Not being into ASP.NET world too much, I still faced a neccessity to work on ASP.NET project that requires periodic deployment of new version to production IIS server.
What are generally accepted best practices for ASP.NET application deployment?
Environment: Windows Server 2003, IIS6, MySQL5, ASP.NET 2.0 application.
Make sure <compiliation debug="false"> is set in your web.config.
Precompile (using a web site application or web deployment projects) to avoid the initial slowdown when accessing the site the first time.
Some time ago I wrote a blog post which targets this approach, having different kind of environments: http://blog.js-development.com/2009/03/best-practices-deploying-webapps-contd_20.html
What I would consider you additionally is to increase the version numbers in your AssemblyInfo for keeping track of the actual version used on the production system.
See How do you do production IIS website depoys? on Server Fault.
Try to execute Production deployments when there are few if any users online, such as at night or weekends. Notify users that there will be a scheduled outage.
When deploying to the production environment, you can create a "App_Offline.htm" file and place it in the root of the ASP.NET website. ASP.NET recognises this file has a special meaning - all dynamic page requests are shown this page instead of the page requested by the user. Typically this page displays a friendly message such as "The server is down for routine maintenance. Please try again in 30 minutes."
Another tip to make deployments less painful is to keep your web.config as similar as possible between your various environments such as Development, Test and Production. For the things that really have to change on the different environments, such as connection strings, you can extract these into their own connectionStrings.config file, by setting in web.config.
For database deployments, there are some great third party tools (such as Teratrax Database Compare for SQL Server) which allow you to compare the schema and/or data between 2 databases and produce a SQL script that will migrate the target database to the schema of the other database. Whether this works for you will depend on your exact development practices. If you cannot use such tools, you could script every database change, then replay those scripts when deploying to a different environment.
And of course you should ideally have a Test environment which is exactly like Production and enables do all your acceptance testing and to ensure your release is stable and your deployment is going to work before you do the real thing.