转载

.net程序集标示与绑定上下文

之前在实现Autofac扫描自加载程序集实现IOC时候遇到程序集依赖的问题，在网上搜了一下，没有发现中文世界的相关描述。随取google拿了几篇文章，翻译&自己的理解，之后会写一些小demo，如下：

相关原文：

http://stackoverflow.com/questions/1477843/difference-between-loadfile-and-loadfrom-with-net-assemblies

http://blogs.msdn.com/b/suzcook/archive/2003/07/21/57232.aspx

http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx

1 、程序集标示

程序集加载有两种标示程序集的策略： 绑定时和绑定后 。标示用来探测一个程序集是否和另一程序集完全相同，或者是否是另外一个程序集所要引用的。

绑定时：用程序集名称来探测是否相同。对非强命名程序集会忽略版本号；可以不用详细指明程序集全名，但是建议总是给出全名，否则就是自己找麻烦。

绑定后即已经加载的程序集：程序集的manifest文件路径是用来探测的标示。对于两个相同的程序集，如果他们的加载路径不同，即使他们内部有完全相同的类型，也不能相互转换。

对于 Load(byte[]) 或者 created by Reflection Emit加载的程序集，总是被判断为不同的程序集，即使他们从二进制上来说完全相同。

2 、程序集绑定上下文

有三种绑定上下文：Load、Load From、其他：

Load context

从GAC、宿主目录(如IIS Cache)、或者ApplicationBase / PrivateBinPaths加载的程序集.

Load From context

通常，用户提供一个不能被加载到Load上下文的路径来加载程序集, 可通过 LoadFrom(), CreateInstanceFrom(), ExecuteAssembly()等方法来加载成Load From上下文。

其他

非以上两种，通过 Assembly.Load(byte[]) 或者Reflection Emit assemblies或者Assembly.LoadFile()加载的。

推荐使用Load上下文，当然另外两种在某些情景下也很有用。

	Advantages	Disadvantages
Load	Gets the benefits of versioning and policy. Best avoids "Dll Hell." Dll Hell can break your app over time. Dependencies available in the Load context are automatically found.	Dependencies in other contexts are not available unless you subscribe to the AppDomain.AssemblyResolve event.
LoadFrom	Assemblies can be loaded from multiple paths, not just from beneath the ApplicationBase. Dependencies already loaded in this context will automatically be found. Dependencies in the same dir as the requesting LoadFrom context assembly will automatically be found.	If a Load context assembly tries to load this assembly by display name, it will fail to be found by default (e.g., when mscorlib.dll deserializes this assembly). Worse, an assembly with the same identity but at a different path could be found on the probing path, causing an InvalidCastException, MissingMethodException, or unexpected method behavior later on. If an assembly by the same identity is already loaded, you'll get that one back, even if you've specified a path to a different one. It does a FileIOPermission.Read + PathDiscovery demand, or a WebPermission demand on the path/URL specified. The ngen image (if any) won't be used. Can't be loaded as domain-neutral. v1.0 and v1.1 CLR only: won't be affected by policy, so can't be centrally serviced.
Neither	Avoids probing costs for loading this assembly. You can load multiple assemblies with the same identity into the same appdomain. You get the bits from the location you specified (as opposed to LoadFrom). Starting in v2, policy/GAC overrides it, however.	Nothing can bind to this assembly unless you've subscribed to the AssemblyResolve event. Dependencies can only be loaded from the Load context or using the AssemblyResolve event. Passing this assembly to another AppDomain may become tricky (e.g., when this is a Reflection Emit assembly that hasn't been saved). The ngen image (if any) won't be used. Can't be loaded as domain-neutral. v1.0 and v1.1 CLR only: won't be affected by policy, so can't be centrally serviced.