. Net Assembly identifier and binding context,. net identifier Context

. Net Assembly identifier and binding context,. net identifier Context

I encountered the Assembly dependency problem when implementing Autofac scanning and self-loading Assembly implementation IOC. I searched the internet and found no description about the Chinese world. Take several articles from google, translate and understand them, and then write some small demos, as shown below:

 

Original article:

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

 

1Assembly ID

An assembly is loaded with two policies that indicate the Assembly:Bind and post-bind. Indicates whether an assembly is exactly the same as another assembly, or whether it is the one to be referenced by another assembly.

Binding:Use the Assembly name to check whether the names are the same. The version number is ignored for a non-strong naming assembly. You do not need to specify the full name of the Assembly in detail, but we recommend that you always give the full name; otherwise, you may find trouble.

The bound assembly:The manifest file path of the Assembly is the identifier used for testing. For two identical assemblies, if they have different loading paths, they cannot be converted to each other even if they have identical types.

For an assembly loaded by Load (byte []) or created by Reflection Emit, it is always regarded as a different assembly, even if they are identical in binary.

2, Assembly binding context

There are three binding contexts: Load, Load From, and others:

Load context

Assembly loaded from GAC, Home Directory (such as IIS Cache), or ApplicationBase/PrivateBinPaths.

Load From context

Generally, you provide a path that cannot be loaded to the Load context to Load the Assembly. You can Load the assembly to the Load From context by using methods such as LoadFrom (), CreateInstanceFrom (), and ExecuteAssembly.

NeitherContext

These two types are loaded through Assembly. Load (byte []), Reflection Emit assemblies, or Assembly. LoadFile.

 

We recommend that you use the Load context. The other two are also useful in some scenarios.

 

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 cocould 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're '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.