This is an introductory post on the internals of CLR Binder.   
 

What does the Binder do?

CLR’s Binder is a piece of code that, when given an assembly name, determines where the assembly is and binds to it.

So how does the Binder locate assemblies?

Let’s assume that you are loading an assembly (let’s call it Foo.dll for the sake of simplicity and sheer lack of imagination) as follows:

Assembly.Load(“Foo, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”);

(As a side note, please make sure that you always specify the fully specified reference of the assembly that you are trying to load. Avoid partial binds at all costs – unless you really know what you’re doing, partial binds are a recipe for disaster. We’ll cover this in more detail in a future post.)

The Binder goes through these steps to determine the desired assembly and it’s location:

1) Applying policy

By ‘policy’, we are referring to different ways in a user can configure assembly binding – to put it simply, think of this as the ability to substitute an assembly name with another.

Now, why would you want to do this?

By providing an option to specify configure assembly binding, developers and administrators can control which versions of assemblies an application will load and use, and provides more flexibility over the way in which managed applications run on specific machines.

Typically, there are three ways in which assembly binding behavior can be configured – you can specify an app.config file, a publisher policy or a machine configuration file (this is not the complete list of the ways in which policy can be specified, but for the sake of simplicity, we leave it at this for now).

The Binder looks at these config files and evaluates the ‘right assembly’ to go pick up.

2) Has the assembly been loaded before?

If the assembly has been loaded before, the runtime uses the assembly already loaded in the same context (notice how the word ‘context’ sneaked in there – we’ll talk about contexts in detail in a future post). Similarly, if loading the same assembly previously failed, subsequent loads are failed without re-trying to load the assembly.

3) Is it in the GAC?

For strong named assemblies, the Binder then looks into the contents of the Global Assembly Cache or the GAC (which is typically used to store assemblies that are shared by more than one application) and if found, picks this up.

4) Where else could it be?

If the Binder finds no match in the previous steps, it checks if the user has already specified locations to pick up the assembly from. This could be in the form of <codeBase> element in your config file, or using the AssemblyName object,(or using LoadFrom or FoadFile). The Binder gets the path and checks for the assembly at this location.

The Binder then resorts to what is called ‘probing’  – this is the process where the Binder starts looking at a specific set of locations for the assembly, the first location being the ‘appbase’.

‘Appbase’ is short for ‘application base’ or which is the root directory where the application to be executed resides in. The Binder examines this directory and it’s subdirectories to find a match for the assembly required to be located.

This post does over-simplify the binding process greatly, but covers the basic aspects of assembly binding in the process. We will talk about each section in detail (and also cover common gotchas)  in future posts in this series.

Aarthi Ramamurthy

PM, CLR