.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上下文。

Neither context

非以上兩種，經過 Assembly.Load(byte[]) 或者Reflection Emit assemblies或者Assembly.LoadFile()加載的。

 

推薦使用Load上下文，固然另外兩種在某些情景下也頗有用。

 

Title	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.