“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.”
What problems do storing common assemblies in the bin directories cause?
Let’s say you host an e-commerce site and you have group of dlls for common tasks such as verifying user information, perhaps some special grid control, shopping cart, some business rules dlls etc. and you have ten different applications for different “stores” and each of these applications all use these common dlls.
If you put these dlls in the bin directories of the applications there are two issues that come to mind immediately:
It is not only the actual space for loading the dlls that makes us use more memory. The information about each class/type, (for example ShoppingCart) and its member variables and methods is stored on the .net loader heap. If you have 10 different dlls (that are really the same) you will store 10 copies of this information on the loader heap. I think you get the pointJ
The solution is to strong name the assemblies and store them in the GAC and if you do need to use different versions for different applications for some reason, this works great as the GAC allows for versioning.
How can you identify it in a memory dump?
You can determine from a hang dump if the same dll is loaded from different locations using either !peb or lm or both…
First through using !peb
!peb lists the process environment block, and with it it lists all the assemblies and where they are loaded from, so if you see the same assembly multiple times in this list, you should think about strong naming them and putting them in the GAC.
15fa0000 403faefe Feb 27 21:56:30 2004 c:\winnt\microsoft.net\framework\v1.1.4322\temporary asp.net files\root\6a24b1eb\ce9dccf3\assembly\dl2\76b0a840\80017dcb_11ffc301\MyAssembly.dll
176a0000 43c6f704 Jan 13 01:40:36 2006 c:\winnt\microsoft.net\framework\v1.1.4322\temporary asp.net files\MySecondApp\da98561f\beac3d80\assembly\dl2\a18f1ad0\ee92e63f_2c19c601\MyAssembly.dll
The second way to tell is by running lm (list modules) and watching out for module names that end with a hex address… The hex address (loading address) is added to the end of the module name to separate multiple assemblies with the same name from each other. If you have not explicitly ngend your dll (created a native image) you should usually not see assemblies ending with addresses. If you do, then seriously consider why… (Note: mscorlib will show up with an address appended because its ngend)
start end module name
15fa0000 15ffc000 MyAssembly (deferred)
176a0000 17712000 MyAssembly_176a0000 (deferred)
PingBack from http://dotnetdebug.net/2006/04/15/tips-for-a-healthy-aspnet-application-in-production/