.net程序集标示与绑定上下文_.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.