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


  1. 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;en-us;813833 PRB: "Access Denied" Error Messages When You Do Not Put Strong-Named Assemblies in the Global Assembly Cache


for specific examples of this.


  1. 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 appdomains”. 


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:windowsassemblygac...  you have spotted an assembly that is strong named but not stored in the GAC, so there is only one thing left to doJ 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:windowsmicrosoft.netframeworkv1.1.4322temporary filesMyApplicatione2b59b515bf1057fassemblydl28b79aa2090288fed_33bfc501MyAssembly.dll



Until next time…

Comments (21)

  1. Recently my colleague Doug wrote a nice post on Nine tips for a healthy &quot;in production&quot; ASP.NET application….

  2. Dan McKinley says:

    Since you say 1.1 specifically, can I assume this is fixed (ie, /bin assemblies loaded differently) in 2.0? I think complying with the GAC recommendation is probably a bigger headache for people than you realize.

  3. Neyah says:

    Does this mean that if two different AppDomains load the same signed DLL that is not in the GAC, that they will share code since the load actually happens in the domain neutral AppDomain?  Or will there be two copies loaded?

    Also, if I load assembly StrongNameNotInGac.dll then my AppDomain recycles and I load StrongNameNotInGac.dll again, are there now two copies of StrongNameNotInGac.dll in the domain neutral AppDomain, or just one?  If there are two, does this mean that the memory taken by the N through N-1 loaded assemblies are "leaked" until the process restarts/recycles?

    You specifically pointed out that this is a problem for ASP.NET 1.1.  Has anything changed in 2.0?

    Based on the FxCop rule that Chris linked to above, I would venture to say that a fair portion of the ASP 1.1 applications deployed here have strong named assemblies in the bin directories 🙁

  4. [JS/CSS] event:Selectors – the simplest way to hook

    Javascript events to a CSS class [Via: Jon


  5. Tess says:


    In 2.0 the assemblies are not loaded domain neutral so you are right:) there was a very specific reason i mentioned 1.1.  (and 1.0 for that matter)


    If you have two strong named assemblies in different directories they are still loaded twice… ASP.NET still wont know that its the same assembly.

    You should not run into the assembly leak you are asking about though… only one dll per unique dll path/name, but i think the question is very valid and i love when people question things like that…

  6. Tess explains in detail why you should not place a strong named assembly into the bin directory of your…

  7. Karl Costenbader says:

    Tess, this may seem unrelated, but your blogs have really got my wheels spinning:

    We have several different applications that our customers can install, each of which has a minimum of 4 different applications (a web client, an application layer hosted in IIS, and a couple of win forms applications). In many cases, the applications are spread over multiple physical machines.

    All of our applications share a set of common DLLs that we have written, but based on customer installation cycles and application distribution patterns, they could have numerous  versions of the common DLLs in the GAC at the same time. For this reason, we have completely shied away from usnig the GAC, but I am becoming more convinced by the day that we need to bite the bullet and start installing to the GAC.

    I am going to assume that you are strongly in favor of installing the common DLLs to the GAC. If so, do you have any pointers/articles on versioning the DLLs or should we just let the compiler pick the next revision number and be done with it? I’m probably overthinking this, but I spent way too much time straightening out DLL versioning issues in the "good old days" to feel completely comfortable about the GAC yet.

    Any tips you can provide would be much appreciated.

  8. The following links to .NET resources have been collated over time with the assistance of colleagues.&amp;nbsp;…

  9. Рекомендую почитать блог &amp;laquo;If broken it is, fix it you should&amp;raquo;. Детально рассматриваются различные…

  10. JohnL says:


    We’re running .Net 2.0 and still have this problem.

    Is this supposed to be fixed in 2.0?

    BTW: the "PRB: "Access Denied" Error Messages…" article you linked to says it applies to .Net 2.0

  11. Tess says:

    Yes,  the issue is due to the dlls being loaded in the shared domain in 1.0 and 1.1. which no longer occurrs in 2.0 so i would say that your issue must be due to something else.

  12. deniz mert edincik says:

    tess, about application recycling;

    what actually happens when application is recycled… we had an issue like logging under bin directory, which caused one of our web services to recycle on each request…

    but I am not sure, is it only performance related or some of the requests can be lost?

    thanks in advance

    deniz aka bluesign

  13. Tess says:

    Hi Deniz,

    The requests that are currently executing will finsih executing but sessions will be lost for example on application restarts.

  14. This is an interesting case I got very recently and that made me scratch my head a lot, wondering what

Skip to main content