.net程序集标示与绑定上下文_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > .net程序集标示与绑定上下文

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

 2015/5/5 13:04:51  12饕餮21  程序员俱乐部  我要评论(0)
  • 摘要:之前在实现Autofac扫描自加载程序集实现IOC时候遇到程序集依赖的问题,在网上搜了一下,没有发现中文世界的相关描述。随取google拿了几篇文章,翻译&自己的理解,之后会写一些小demo,如下:相关原文:http://stackoverflow.com/questions/1477843/difference-between-loadfile-and-loadfrom-with-net-assemblieshttp://blogs.msdn
  • 标签:程序 .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.
发表评论
用户名: 匿名