什么3种结合上下文进行的？ [英] What are 3 kinds of Binding Contexts for?

问题描述

我知道，有3个不同的结合上下文或负载背景：

 加载
LoadFrom
LoadNeither
 

1. 什么是负载环境？
2. 又是为了什么？
3. 为什么要组装装这么复杂？
4. 在LoadNeither，既不是是什么？

在此先感谢...

---------------以下是一些有用的报价我最近发现--------------------

了解情况

在粘合剂上没有文章是不完整的解决装载机背景和其存在的理由。装载机上下文是经常混淆的来源。想想装载机上下文为持有组件的应用程序域内的逻辑桶。根据如何在组件正在加载，他们分为三个装载机背景之一。

加载上下文简单地说，这是present无论是在GAC中，还是在ApplicationBase，或在ApplicationBase的PrivateBinPath的所有组件，正在使用的Assembly.Load加载将在负载上下文加载。组件使用AssemblyResolve事件也属于这一类解决。

LoadFrom上下文如果您正试图通过提供的ApplicationBase之外的特定的路径来加载程序集，而议会将不会被在负载情况下找到，则装配在装在LoadFrom上下文。

无论是背景如果您正试图加载使用Assembly.LoadFile（）的组件，的Assembly.Load（byte []的），或Reflection.Emit的，这些组件加载到无论是背景。

在装入LoadFrom上下文组件的情况下，该活页夹首先检查，查看是否确切组件（相同的身份和位置）已经是在$ Load上下文p $ psent。如果是，则丢弃在LoadFrom上下文的组件信息，并使用从Load上下文中的程序集信息。在确定是否是相同的组件，位置信息是非常重要的，我们会很快涉及这一点。在.NET Framework 1.1中，这被称为LoadFrom的第二个绑定，因为活页夹用来执行两个步骤，首先将在LoadFrom上下文的组件，然后促进它移交给负载情况下，如果找到匹配的程序集标识和位置在负载范围内。

请确保该程序集加载到负载情况下尽可能多地。为此，大会应该从海关总署的ApplicationBase，或在AppDomain的PrivateBinPath可定位。组件装入这种情况下自动获得NGEN的利益和组装的依赖present在这种情况下被自动拾取。

装载程序集到LoadFrom上下文有自己的优势，它可以让ApplicationBase外多个组件，以通过指定路径来加载。

现在，让我们来谈谈装配的位置，同时确定是否通过LoadFrom（）加载的程序集是一样的，大会通过Load加载（）。即使在两个组件的类型是相同的，如果两个组件被从不同的路径加载，它们不认为是相同的，只要加载上下文而言。这导致其中相同的组件被以相同的应用领域反复加载的情况，但为不同的上下文（负载和LoadFrom）和在负载上下文的组件的类型将不被允许为相同类型的LoadFrom上下文（即使它们是相同的组件，只要该组件标识而言）。这是LoadFrom的缺点之一。另外，在LoadFrom上下文组件并不自动收获NGEN的好处。

至于既不上下文，在此上下文组件不能被结合到，除非应用程序预订了AssemblyResolve事件。一般应避免这样的背景下。

那么，为什么CLR在首位装载机背景？装载机上下文有助于确保加载顺序无关，而加载的程序集。此外，它们提供隔离的量度当它们被加载到不同的上下文组件及其依赖性。

- 从理解CLR粘合剂

解决方案

有可能只有少数人谁可以回答这个问题的为什么的一部分。负载环境大多都与如何依赖关系的约束。我的理解是：

• 加载，加载使用传统的位置，并结合方法汇编成的AppDomain 。加载的组件可作为一个依赖在负荷装载后续组件上下文。
• LoadFrom ，加载一个组件插入的AppDomain 寻找像加载依赖，但有一点不同：这些组件将不会被用于解决加载环境组件的依赖
。
• LoadNeither 负载只是一个程序集。如果有未解决的依赖性，则需要通过 AssemblyResolve 事件，以解决他们自己。

这是一个关于它的伟大的博客： <一href="http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx">http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

I know that there are 3 different binding contexts or load contexts:

Load
LoadFrom
LoadNeither

1. What are load contexts?
2. What are they for?
3. Why make the assembly loading so complicated?
4. In "LoadNeither", "neither" of what?

Thanks in advance...

--------------- Following are some useful quotations I recently found --------------------

Understand the Context

No article on the Binder is complete without addressing loader contexts and the reason for their existence. Loader contexts are often the source of confusion. Think of loader contexts as logical buckets within an application domain that hold assemblies. Depending on how the assemblies were being loaded, they fall into one of three loader contexts.

Load context To put it simply, all assemblies that are present either in the GAC, or in the ApplicationBase, or in the PrivateBinPath under the ApplicationBase, that are loaded using Assembly.Load will be loaded in the Load context. Assemblies resolved using the AssemblyResolve event also fall in this category.

LoadFrom context If you are attempting to load an assembly by providing a specific path that is outside the ApplicationBase, and the assembly would not have been found in the Load context, then the assembly is loaded in the LoadFrom context.

Neither context If you are attempting to load an assembly using Assembly.LoadFile(), Assembly.Load(byte[]), or Reflection.Emit, those assemblies are loaded into the Neither context.

In the case of assemblies loaded into the LoadFrom context, the Binder first checks to see if the exact assembly (same identity and location) is already present in the Load context. If it is, it discards the assembly information in the LoadFrom context and uses the assembly information from the Load context. In determining whether it is the same assembly, the location information is important, and we'll cover this shortly. In .NET Framework 1.1, this was known as LoadFrom's second bind, since the Binder used to perform two steps—first to place the assembly in the LoadFrom context, and then promote it over to the Load context if it found a matching assembly identity and location in the Load context.

Make sure that the assembly is loaded into the Load context as much as possible. For this, the assembly should be locatable from the GAC, the ApplicationBase, or the PrivateBinPath of the AppDomain. Assemblies loaded into this context automatically get benefits of NGen and the assembly's dependencies present in this context are automatically picked up.

Loading assemblies into the LoadFrom context has its own advantages—it allows multiple assemblies outside the ApplicationBase to be loaded by specifying their paths.

Now, let's talk about the location of the assembly, while identifying if the assembly loaded via LoadFrom() is the same as the Assembly loaded via Load(). Even if the types in two assemblies are identical, if the two assemblies are loaded from different paths, they are not considered identical as far as loader contexts are concerned. This leads to situations where the same assembly is loaded repeatedly in the same application domain, but into different contexts (Load and LoadFrom) and a type in the assembly in the Load context will not be allowed to be the same type in the LoadFrom context (even if they are the same assemblies as far as the assembly identities are concerned). This is one of the disadvantages of LoadFrom. Also, assemblies in the LoadFrom context do not automatically reap the benefits of NGen.

As for the Neither context, assemblies in this context cannot be bound to, unless the application subscribes to the AssemblyResolve event. This context should generally be avoided.

So why does the CLR have loader contexts in the first place? Loader contexts help ensure load-order independence while loading assemblies. In addition, they provide a measure of isolation to assemblies and their dependencies when they are loaded into different contexts.

-- From Understanding The CLR Binder

解决方案

There are probably only a few people who can answer the "why" part of the question. The load contexts mostly have to do with how dependencies are bound. My understanding is that:

• Load, loads an assembly into the AppDomain using "traditional" location and binding methods. The loaded assembly can be used as a dependency for subsequent assemblies loaded in the Load context.
• LoadFrom, loads an assembly into the AppDomain finding dependencies like Load but with one difference: these assemblies will not be used to resolve the dependencies of Load context assemblies.
• LoadNeither loads just that one assembly. If it has unresolved dependencies, you will need to resolve them yourself via the AssemblyResolve event.

This is a great blog about it: http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

这篇关于什么3种结合上下文进行的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！