Top 10 Best Practices for Production ASP.NET Applications

In no particular order, here are the top ten things I've learned to pay attention to when dealing with production ASP.NET applications.  Hopefully they will help you save you some time and headaches.  As always, your thoughts and additions are welcome.

1.  Generate new encryption keys

When moving an application to production for the first time it is a good idea to generate new encryption keys.  This includes the machine validation key and decryption key as well as any other custom keys your application may be using.  There is an article on CodeProject that talks about generating machineKeys specifically that should be helpful with this.

2.  Encrypt sensitive sections of your web.config

This includes both the connection string and machine key sections.  See Scott Guthrie's post for some good references.  Note that if your application runs in a clustered environment you will need to share a custom key using the RSA provider as described in an MSDN article.

3.  Use trusted SQL connections

Both Barry Dorrans and Alex Chang have articles which discuss this in detail.

4.  Set retail="true" in your machine.config

    <configuration>
    <system.web>
    <deployment retail="true"/>
    </system.web>
    </configuration>

    This will kill three birds with one stone.  It will force the 'debug' flag in the web.config to be false,  it will disable page output tracing, and  it will force the custom error page to be shown to remote users rather than the actual exception or error message.  For more information you can read Scott Guthrie's post or the MSDN reference.

5.  Create a new application pool for your site

When setting up your new site for the first time do not share an existing application pool.  Create a new application pool which will be used by only by the new web application.

6.  Set the memory limit for your application pool

When creating the application pool, specifically set the memory limit rather than the time limit which is set by default.  Asp.net has a good whitepaper which explains the value of this:

By default IIS 6.0 does not set a limit on the amount of memory that IIS is allowed to use. ASP.NET’s Cache feature relies on a limitation of memory so the Cache can proactively remove unused items from memory.

It is recommended that you configure the memory recycling feature of IIS 6.0.

7.  Create and appropriately use an app_Offline.htm file

There are many benefits to using this file.  It provides an easy way to take your application offline in a somewhat user friendly way (you can at least have a pretty explanation) while fixing critical issues or pushing a major update.  It also forces an application restart in case you forget to do this for a deployment.  Once again, ScottGu is the best source for more information on this.

8.  Develop a repeatable deployment process and automate it

It is way too easy to make mistakes when deploying any type of software.  This is especially the case with software that uses configuration files that may be different between the development, staging, or production environments.  I would argue that the process you come up with is not nearly as important as it being easily repeatable and automated.  You can fine tune the process as needed, but you don't want a simple typo to bring a site down.

9.  Build and reference release versions of all assemblies

In addition to making sure ASP.NET is not configured in debug mode, also make sure that your assemblies are not debug assemblies.  There are of course exceptions if you are trying to solve a unique issue in your production environment ... but in most cases you should always deploy with release builds for all assemblies.

10.  Load test

This goes without saying.  Inevitably, good load testing will uncover threading and memory issues not otherwise considered.

kick it on DotNetKicks.com

 

Need a better way to manage your content?

Filed under:

Leave a Comment

Comments

  • José Lema said:

    Great post Kyle!

    Not sure how I missed it, but I don't ever recall seeing the <deployment retail="true" /> feature.

    12 Feb, 2008 @ 10:26 PM
  • Kyle said:

    Thanks Jose!

    I actually learned that one from Steve Schofield at ORCS Web.  It's one of those not often talked about but really valuable tips.

    13 Feb, 2008 @ 06:47 AM
  • JV said:

    The most important one from an ASP.NET point of view is missing: Set <compilation debug="true"> to <compilation debug="false">

    14 Feb, 2008 @ 12:30 AM
  • Tim Hustler said:

    Very nice set of points.  when you're knee-deep in the code it's easy to forget the little steps which go on to make your apps run that little bit more smoothly

    Thanks for posting :¬)

    14 Feb, 2008 @ 02:01 AM
  • Shannon said:

    "The most important one from an ASP.NET point of view is missing: Set <compilation debug="true"> to <compilation debug="false">"

    That's there, at machine level instead of web.config level.. retail="true"

    14 Feb, 2008 @ 07:03 AM
  • Kyle said:

    @JV,

    It's easy to miss, but #4 is supposed to keep you from having to worry about that one.  

    However, you're right that it is still a good practice to set the debug flag false in case your application is deployed to a server that doesn't have the modified machine.config for one reason or another.

    @Tim Hustler,

    Thanks for you comment and your trackback.  I've also posted a comment on your post about stress testing tools.

    14 Feb, 2008 @ 07:08 AM
  • Guillermo said:

    That "<deployment retail="true" /> is awesome.

    Very good post.

    14 Feb, 2008 @ 08:16 AM
  • Amr Elsehemy said:

    This is one awesome very useful post, thanks.

    <deployment retail="true"/> WOW.

    14 Feb, 2008 @ 10:28 AM
  • Will Asrari said:

    Setting compilation debug equal to false is very important.  That was a valuable tip shared by Scott Guthrie at a presentation I attended recently.

    When deployment retail is set to true ASP.NET disables, amongst other things; custom errors. What would this mean for an application utilizing custom error pages / redirects?

    14 Feb, 2008 @ 10:45 AM
  • Kyle said:

    @Guillermo, @Amr Elsehemy - Glad you found it useful.

    @Will Asrari,

    The wording is a bit turned around on that one.  Essentially what it means is that the 'mode' attribute of the 'customErrors' element is forced to "On".  So, your custom error pages will always be shown instead of the ASP.NET error page.

    14 Feb, 2008 @ 01:37 PM
  • Will Asrari said:

    Thanks Kyle! Perfect.

    14 Feb, 2008 @ 01:59 PM
  • Bill Robertson said:

    Do you have any thoughts on deleting old PDB files before deploying?  Do they slow anything down.

    14 Feb, 2008 @ 03:17 PM
  • Lucio said:

    Why is a separate application pool better? Can you refer me to somewhere where this is discussed?

    Thanks for the post

    15 Feb, 2008 @ 02:47 AM
  • Kyle said:

    @BillRob,

    Not sure why, but I feel like you're asking a trick question. :)  The only reason I can think of that someone would ever deploy PDB files is if there is an issue that needs debugged and it can't be reproduced in any other environment.  Is there any other good reason to deploy PDB files?

    Or, are you just saying it would be good to add that as a tip to the list ... to make sure they aren't deployed?

    15 Feb, 2008 @ 07:07 AM
  • Kyle said:

    @Lucio,

    Sorry, I don't know of a good place where that is discussed.  

    I do think it is really important though.  The reason is that it isolates your site from the problems of other applications on your server.  You can think of it this way ... when your site shares an application pool, you are essentially giving any other applications in that pool the right to restart your site at any time.  For example if an application exceeds the memory limits of the app pool or causes any other condition to restart the app pool every other application in that pool will also be restarted.

    The bottom line is that if you put a single application in an app pool it will likely be more stable and perform better over the long run.

    Obviously, there are other considerations such as the hardware your site is running on and how many other web applications are running on the same server ... but that is too long to discuss here.

    I hope that answers your question and if you find a good resource on this subject be sure to share.

    15 Feb, 2008 @ 07:38 AM
  • Lucio said:

    Thanks for the answer, Kyle!

    Looks like the decision to use a separate application pool would require insight on two things: how many worker processes (app. pools) you are able to withstand with your hardware and how well you know every other application that may be running in the same app. pool as yours, that is, if you want stability it's good to know how the other web apps can fail and how badly.

    This is not exactly a discussion on app. domains, but I found it while browsing and it's a good article on the asp.net architecture in general: www.west-wind.com/.../howaspnetworks.asp

    Regards

    15 Feb, 2008 @ 10:21 AM
  • Kyle said:

    @Lucio,

    Well said ... and good resource.

    15 Feb, 2008 @ 11:06 AM
  • Dmitry Lyalin said:

    Very good post, I definitely learning a few things from it and I consider myself a seasoned .NET developer :).

    17 Feb, 2008 @ 11:34 AM
  • Ray Zhang said:

    Very good summary,

    thanks buddy!

    17 Feb, 2008 @ 11:46 PM
  • 'Anil' Radhakrishna said:

    There is one more interesting list by K. Scott Allen on the same topic:

    10 Tips for Shrink-wrapping ASP.NET Applications - odetocode.com/.../11365.aspx

    18 Feb, 2008 @ 04:03 AM
  • PWills said:

    While creating your new AppPool, go ahead and take 30 seconds to create a dedicated Active Directory account to use as the identity for that AppPool. Advantages:

    - SQL Server will now be tell you which application is which (if 'Integrated Security=True').

    - Task Manager will now tell you which PID belongs to which application.

    18 Feb, 2008 @ 05:31 AM
  • Kyle said:

    @Dmitry, @Ray - Glad you found it useful!

    @Anil - Thanks for the link.  Definately some good tips from K. Scott Allen.

    @PWills - Very good tip, thanks!

    18 Feb, 2008 @ 07:24 AM
  • Mark Aurit said:

    Would be nice if you listed your rationale for each.  

    18 Feb, 2008 @ 08:54 AM
  • Kyle said:

    @Mark,

    I attempted to briefly mention rationale where it seemed appropriate ... but also wanted to keep it short and to the point.

    Are there any points in particular for which you would like a more detailed explanation?  Do you have any specific questions?

    18 Feb, 2008 @ 09:12 AM
  • psanders said:

    Interesting article. Showed some good practices for secrity lockdown issues.  But mostly common sense and good practices.

    20 Feb, 2008 @ 06:58 AM
  • Rob Mills said:

    I am still surprised at how many developers don't worry about compiling release versions of their assemblies for the production deployment.

    Good tips!

    20 Feb, 2008 @ 06:06 PM
  • Abhijeet Rajwade said:

    Simple but very helpful article.

    Thanks!!!

    21 Feb, 2008 @ 11:59 PM
  • oyun said:

    Thanks Kyle! Perfect.

    25 Feb, 2008 @ 11:39 AM
  • Brian said:

    When you experience issues with an app pool -- ie) bad code....what techniques/tools are available to help you track down what is causing the problem(s) ?

    06 Mar, 2008 @ 11:47 AM

Trackbacks

  • from DotNetKicks.com on 13 Feb, 2008

    You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • from purrl.net |** urls that purr **| on 13 Feb, 2008

    These are the web's most talked about URLs on Thu 14th Feb 2008. The current winner is ..

  • from Creative Jar Blog on 14 Feb, 2008

    ASP.NET Set Live Checklist

  • from Information Technology on 14 Feb, 2008

    In no particular order, here are the top ten things I&#39;ve learned to pay attention to when dealing

  • from ScottGu's Blog on 17 Feb, 2008

    Here is the latest in my link-listing series .&#160; Also check out my ASP.NET Tips, Tricks and Tutorials

  • from BusinessRx Reading List on 17 Feb, 2008

    Here is the latest in my link-listing series .&#160; Also check out my ASP.NET Tips, Tricks and Tutorials

  • from Sunny Nagi on 17 Feb, 2008

    Top 10 Best Practices for Production ASP.NET Applications is a must read for anyone developing ASP.NET

  • from Beyond Web Logs - Success Here and Hereafter on 17 Feb, 2008

    Best Practices for Production ASP.NET Applications

  • from Hilton Giesenow's Jumbled Mind on 19 Feb, 2008

    I found a nice series of tips for releasing ASP.Net apps to production via Scott Guthrie&#39;s links

  • from Mirrored Blogs on 19 Feb, 2008

    Here is the latest in my link-listing series .&#160; Also check out my ASP.NET Tips, Tricks and Tutorials

  • from TerryLee on 20 Feb, 2008

    概述春节后的第一期推荐系列文章,共有10篇文章:1.ASP.NETMVCExampleApplicationoverNorthwindwiththeEntityFramework...

  • from Jacky_Xu on 20 Feb, 2008

    概述 春节后的第一期推荐系列文章,共有10篇文章: 1.ASP.NETMVCExampleApplicationoverNorthwindwiththeEntityFr...

  • from ASP.NET on 22 Feb, 2008

    Read this nice post that summarizes a number of good best practices to follow when deploying your ASP

  • from CallContext on 28 Feb, 2008

    Here is a nifty (and Web 2.0!!) post about what you should do when deploying an ASP.NET application into...

  • from Programming on 06 Mar, 2008

    Here is the latest in my link-listing series .&#160; Also check out my ASP.NET Tips, Tricks and Tutorials

  • from ASP.NET Debugging on 11 Mar, 2008

    One of the really useful, and not well-known features of ASP.NET 2.0 is that you can use a special file

  • from Noticias externas on 11 Mar, 2008

    One of the really useful, and not well-known features of ASP.NET 2.0 is that you can use a special file

  • from Mirrored Blogs on 12 Mar, 2008

    ASP.NET Debugging : Bringing down an ASP.NET Application for updates &quot;One of the really useful,

  • from HaginsGroup.com on 14 Mar, 2008

    .NET Goodness

  • from ScottGu Italian on 10 Jun, 2008

    Colegamenti del 17 Febbraio: ASP.NET, ASP.NET AJAX, Visual Studio, .NET

  • from Excite Internet on 01 Jul, 2008

    Useful Link - Top 10 Best Practices for Production ASP.NET Applications

  • from 真见 on 21 Jul, 2008

  • from cnblogs.com on 22 Jul, 2008

    本来是想整合到 Always 英文技术文章参照 系列中去的, 但是要延迟了,先把今天收集的贴出来,个人觉得还可以。。 强烈推荐:为什么我的asp.net Ajax的形式从来没有提交过两次 。 强烈推荐