Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.