ASP.NET Strong named assemblies should not be stored in the bin directory

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).

What problems do storing strong named assemblies in the bin directories cause

In ASP.NET 1.1, strong named assemblies are loaded as “domain neutral”.

As you probably already know every asp.net application lives in its own application domain (a unit of isolation inside an application), and assemblies used by this application are loaded up inside the domain. If the app domain is recycled because you modify the applications web.config, or change the bin directory or similar, the assemblies loaded in this domain are unloaded with the domain.

This is true for all assemblies that are not strong named. For example, you wouldn’t want System.Web.dll loaded up into each application domain as it would mean that System.Web.dll would be loaded once for each application, bad bad bad!!! So strong named assemblies, irrespectively of where they are loaded from are loaded into a shared domain (they are domain neutral).

There are two types of issues you can run into because of this

Locking

Since the assemblies in the shared domain are not unloaded when the app domain unloads they may get locked if you are unlucky with timing. Locking issues most frequently occur with processes that frequently scan folders such as index server, virus scanning software or backup software.

See PRB: “Can not Access File ‘AssemblyName’ Because It Is Being Used by Another Process” Error Message in ASP.NET” and PRB: “Access Denied” Error Messages When You Do Not Put Strong-Named Assemblies in the Global Assembly Cachefor specific examples of this.

Code access security errors

If a strong named assembly is used by multiple web applications and each application grants it varying permissions or if the permission grant varies between application domain restarts, you might see errors like “Assembly <assembly>.dll security permission grant set is incompatible between app domains”.

You may also see other code access security errors since you access an assembly outside of your application domain. Normally full-trust is granted to assemblies in the GAC, but these aren’t in the GAC so they may not have full trust.

For these reasons it is not supported to store strong named assemblies in the bin directories of ASP.NET applications in 1.1.

How can you identify it in a memory dump

If you run !dumpdomain and go through the assemblies showing up in the shared domain you will see all the assemblies loaded up in the process that are strong named.

If you see one whose path is not c:\windows\assembly\gac... you have spotted an assembly that is strong named but not stored in the GAC, so there is only one thing left to do - GAC it!!!

Here is an example of how this looks for my strong named assembly called MyAssembly.dll that is stored in the bin directory of MyApplication.

0:000> !dumpdomain
...
Shared Domain: 0x793f2b70
LowFrequencyHeap: 0x793f2bd4
HighFrequencyHeap: 0x793f2c2c
StubHeap: 0x793f2c84
...
Assembly: 0x21ddcd0 [MyAssembly]
ClassLoader: 0x021d5158
  Module Name
0x021e99a8 c:\windows\microsoft.net\framework\v1.1.4322\temporary asp.net files\MyApplication\e2b59b51\5bf1057f\assembly\dl2\8b79aa20\90288fed_33bfc501\MyAssembly.dll

Until next time