Question

I know that there are 3 different binding contexts or load contexts:

Load
LoadFrom
LoadNeither

1. What are load contexts?
2. What are they for?
3. Why make the assembly loading so complicated?
4. In “LoadNeither”, “neither” of what?

Thanks in advance…

————— Following are some useful quotations I recently found ——————–

Understand the Context

No article on the Binder is complete without addressing loader contexts and the reason for their existence. Loader contexts are often the source of confusion. Think of loader contexts as logical buckets within an application domain that hold assemblies. Depending on how the assemblies were being loaded, they fall into one of three loader contexts.

Load context To put it simply, all assemblies that are present either in the GAC, or in the ApplicationBase, or in the PrivateBinPath under the ApplicationBase, that are loaded using Assembly.Load will be loaded in the Load context. Assemblies resolved using the AssemblyResolve event also fall in this category.

LoadFrom context If you are attempting to load an assembly by providing a specific path that is outside the ApplicationBase, and the assembly would not have been found in the Load context, then the assembly is loaded in the LoadFrom context.

Neither context If you are attempting to load an assembly using Assembly.LoadFile(), Assembly.Load(byte[]), or Reflection.Emit, those assemblies are loaded into the Neither context.

In the case of assemblies loaded into the LoadFrom context, the Binder first checks to see if the exact assembly (same identity and location) is already present in the Load context. If it is, it discards the assembly information in the LoadFrom context and uses the assembly information from the Load context. In determining whether it is the same assembly, the location information is important, and we’ll cover this shortly. In .NET Framework 1.1, this was known as LoadFrom’s second bind, since the Binder used to perform two steps—first to place the assembly in the LoadFrom context, and then promote it over to the Load context if it found a matching assembly identity and location in the Load context.

Make sure that the assembly is loaded into the Load context as much as possible. For this, the assembly should be locatable from the GAC, the ApplicationBase, or the PrivateBinPath of the AppDomain. Assemblies loaded into this context automatically get benefits of NGen and the assembly’s dependencies present in this context are automatically picked up.

Loading assemblies into the LoadFrom context has its own advantages—it allows multiple assemblies outside the ApplicationBase to be loaded by specifying their paths.

Now, let’s talk about the location of the assembly, while identifying if the assembly loaded via LoadFrom() is the same as the Assembly loaded via Load(). Even if the types in two assemblies are identical, if the two assemblies are loaded from different paths, they are not considered identical as far as loader contexts are concerned. This leads to situations where the same assembly is loaded repeatedly in the same application domain, but into different contexts (Load and LoadFrom) and a type in the assembly in the Load context will not be allowed to be the same type in the LoadFrom context (even if they are the same assemblies as far as the assembly identities are concerned). This is one of the disadvantages of LoadFrom. Also, assemblies in the LoadFrom context do not automatically reap the benefits of NGen.

As for the Neither context, assemblies in this context cannot be bound to, unless the application subscribes to the AssemblyResolve event. This context should generally be avoided.

So why does the CLR have loader contexts in the first place? Loader contexts help ensure load-order independence while loading assemblies. In addition, they provide a measure of isolation to assemblies and their dependencies when they are loaded into different contexts.

— From Understanding The CLR Binder

Answer 1

There are probably only a few people who can answer the “why” part of the question. The load contexts mostly have to do with how dependencies are bound. My understanding is that:

• Load, loads an assembly into the AppDomain using “traditional” location and binding methods. The loaded assembly can be used as a dependency for subsequent assemblies loaded in the Load context.
• LoadFrom, loads an assembly into the AppDomain finding dependencies like Load but with one difference: these assemblies will not be used to resolve the dependencies of Load context assemblies.
• LoadNeither loads just that one assembly. If it has unresolved dependencies, you will need to resolve them yourself via the AssemblyResolve event.

This is a great blog about it:
http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx