ASP.NET: Check your Web Site today for these common assembly related memory and perf issues

Recently my colleague Doug wrote a nice post on Nine tips for a healthy “in production” ASP.NET application.

I have been planning to post about some of these for a while, so I decided to steal some of his points and expand a bit on them, and also show you how you can identify them in a memory dump.

As most of you know I like to go into great detail about thingsJ so to make it a bit more manageable I have divided my posts up into 3 different parts (one per statement that Doug makes in his post).

• Ensure that the debug="false" on the compilation element in the web.config file of each and every ASP.NET application on the server. The default during development is “true” and it is a common mistake to allow this development time setting to find its way onto production servers during deployment. You don’t need it set to true in production and it often leads to memory overhead and inefficiencies.
• Wherever possible strong name and install to the global assembly cache (GAC) any assemblies that are used by more than one ASP.NET application. This will reduce memory consumption.
• In ASP.NET 1.1, do not deploy strong named assemblies to the BIN directory (i.e. if they are strong named make sure you DO put them in the GAC).

Don’t wait tomorrow to get your application “health-checked” go out there and grab some hang dumps today…