A first hand look from the .NET engineering teams
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=188.8.131.52, 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.
PingBack from http://www.clickandsolve.com/?p=2061
Thanks for getting the comments going!
I was interested to see your piece on the CLR Binder. This could be a useful new resource. People in my office often come to me with assembly loading/binding problems, and I always point them here:-
This seems to sort out their problems. Scott Hanselman is also a huge fan:- http://www.hanselman.com/blog/FusionLoaderContextsUnableToCastObjectOfTypeWhateverToTypeWhatever.aspx
I was wondering if you were going to cover new or different material to Richard Grimes. E.g. is the .NET 4 CLR going to change wrt to binding/loading?
Suzanne Cook's (unfortunately now defunct) blog has been a really useful resource for me in the past: http://blogs.msdn.com/suzcook/default.aspx. And of course the Assembly binding log viewer: http://msdn.microsoft.com/en-us/library/e74a18c4(VS.80).aspx
I think some of the more complex scenarios get overlooked in binder information.
I had fun when I was writing an ActiveX control hosted in an unmanaged project. The main control is loaded based on the CodeBase specified as part of the COM registration (i.e. in the registry).
However the binder tries to load satellite assemblies from the path of the running unmanaged executable - which I had no control over - rather than the Codebase of the COM control (which was in a different folder). I got around it by handling the AssemblyResolve event. I'm still a little unsure what would happen if another assembly running in the same process also handled that event ....?
What I don't understand is why there isn't an easy way to force/suggest a global load location programatically and/or using config. After all I know where my assemblies live ...
One way would be to allow us to add folders the front of the probing path collection.
Thanks for the post Aarthi - I'm (scarily) looking forward to the post on load contexts as I'm not sure I ever got my head around that completely. I'd especially like to see an explanation of why they exist in the first place...
Thanks for the link on Richard Grimes' workshop material. That does seem extremely useful.
While the content that I plan to cover does intersect with this, I plan to cover specific problems/pain points that people ask my team as well, along with new content specific to v4.0.
It is (unfortunately) true that parts of the Binder's behavior are not very straightforward.
I was planning on covering ResolveEvent pretty soon, but to answer your question - AssemblyResolve event is only a multicat delegate, so if another assembly also handles the same event, it leads to the classic case of non-determism.
And yes, a post on loader contexts are coming up soon! Thanks for reading..