之前在实现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.
|
