1) Do not run production ASP.NET Applications with debug=”true” enabled.

Doing so causes a number of non-optimal things to happen including:

• · The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
• · Code can execute slower (since some additional debug paths are enabled)
• · Much more memory is used within the application at runtime
• · Scripts and images downloaded from the WebResources.axd handler are not cached (This is most important)

Using debug = “true” reduces performance drastically. We can check performances easily using RAD Toolkits (Telerik/Atlas), Treeview/Menu/Validator etc.

2) Try to use Trusted Connection for Database

This is the Microsoft Suggested Practice for developing secured web application. Some excellent articles are here for why and how to do this … http://weblogs.asp.net/achang/archive/2004/04/15/113866.aspx or http://idunno.org/articles/276.aspx

3) Encrypt sensitive sections of your configuration files.

This is another Microsoft Suggested Practice for developing secured web application. Our Encryption Keys, Machine Keys or Database Connection must be secured in our configuration. This encryption is pretty simple but really useful. Execute the code from command prompt:

For encrypt: aspnet_regiis.exe -pe "appSettings" –app "/test_solution"

For decrypt: aspnet_regiis.exe -pd "appSettings" –app "/test_solution"

Here "test_solution" is the virtual location (hosting) where the web.config file should exist and “appSettings” is the section we want to encrypt.

For executing you need to set your .net Framework version path in system path.

Reference: http://msdn.microsoft.com/en-us/library/zhhddkxy(v=VS.90).aspx

4) Always show custom error page instead of actual error.

This need not explanation as everybody knows actual error shows the page name, line no and codes, variable names as well which is really dangerous for production version.

5) Set The <deployment retail=”true”/> Switch in Maching.config

This is the best solution for handling 3 common errors like debug is enabled or trace is enabled or custom error is off. It will handle all those errors automatically. Add the following in your Machine.Config file

<configuration>

<system.web>

<deployment retail=”true”/>

</system.web>

</configuration>

Reference: http://msdn.microsoft.com/en-US/library/ms228298(VS.80).aspx

6) Set the memory limit for the application pool instead of time limit.

For time limit app pool recycles after the limit or interval. It always should be recycling after it reaches the memory limit otherwise it will acquire unnecessary memory. Several articles on this are available as http://support.microsoft.com/kb/332088 or http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx

7) Always try to develop a repeatable deployment process and automate it.

It’s not a good practice of deploying application manually. In this case we often forgot to include updates or re-deploy the whole assembly (often whole assembly deployment is not required, need to deploy only dependent assemblies). We need to find out a good automated solution for deployment process. Here is a nice article how to Automating Deployment with Microsoft Web Deploy… http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx or managing staging... http://weblogs.asp.net/scottgu/archive/2007/09/21/tip-trick-automating-dev-qa-staging-and-production-web-config-settings-with-vs-2005.aspx