Что такое 3 типа связующих контекстов?

Question

Я знаю, что есть 3 различные обязательные контексты или контексты нагрузки:

Load 
LoadFrom 
LoadNeither 

1. Что контексты нагрузка?
2. Для чего они предназначены?
3. Зачем загружать сборку настолько сложно?
4. В «LoadNeither», «ни» чего?

Заранее спасибо ...

--------------- Ниже приведены некоторые полезные цитаты Недавно я нашел ----------- ---------

не понять контекст

нет статьи о Binder является полным без решения загрузчика контекстов и причины их существования. Конфликты загрузчика часто являются источником путаницы. Подумайте о контекстах загрузчика как о логических ведрах в домене приложения, в котором хранятся сборки. В зависимости от того, как загружаются сборки, они попадают в один из трех контекстов загрузчика.

контекст Load Проще говоря, все узлы, которые присутствуют либо в GAC, или в ApplicationBase, или в PrivateBinPath под ApplicationBase, которые загружаются с помощью Assembly.Load будет загружен в контексте нагрузки , Ассембли, разрешенные с использованием события AssemblyResolve, также попадают в эту категорию.

контекст LoadFrom Если вы пытаетесь загрузить сборку, обеспечивая определенный путь, который находится за пределами ApplicationBase, а сборка не были найдены в контексте нагрузки, то сборка загружается в контекст LoadFrom.

Ни контекст Если вы пытаетесь загрузить сборку с помощью Assembly.LoadFile(), Assembly.Load (байт []), или Reflection.Emit, эти узлы будут загружены в Ни контекст.

В случае сборок, загружаемых в контекст LoadFrom, Binder сначала проверяет, присутствует ли точная сборка (такая же идентификация и местоположение) в контексте загрузки. Если это так, он отбрасывает сборку в контексте LoadFrom и использует информацию о сборке из контекста загрузки. При определении того, является ли это одной и той же сборкой, важна информация о местоположении, и мы вскоре рассмотрим ее. В .NET Framework 1.1 это было известно как второе связывание LoadFrom, поскольку Binder использовал два этапа: сначала поместить сборку в контекст LoadFrom, а затем передать ее в контекст Load, если он нашел соответствующий идентификатор сборки и местоположение в контексте загрузки.

Убедитесь, что сборка загружена в контекст нагрузки как можно больше. Для этого сборка должна быть локализована из GAC, ApplicationBase или PrivateBinPath из AppDomain. Ассембли, загруженные в этот контекст, автоматически получают преимущества NGen, и зависимости сборки, присутствующие в этом контексте, автоматически подбираются.

Загрузка сборок в контекст LoadFrom имеет свои преимущества: он позволяет загружать несколько сборок вне ApplicationBase, указывая их пути.

Теперь давайте поговорим о расположении сборки, идентифицируя, что сборка, загруженная через LoadFrom(), совпадает с сборкой, загруженной через Load(). Даже если типы в двух сборках идентичны, если две сборки загружены из разных путей, они не считаются идентичными по отношению к контекстам загрузчика. Это приводит к ситуациям, когда одна и та же сборка повторно загружается в одном домене приложения, но в разные контексты (Load и LoadFrom), а тип в сборке в контексте загрузки не может быть одним и тем же типом в контексте LoadFrom (даже если они являются одними и теми же сборками в отношении идентификаторов сборки). Это один из недостатков LoadFrom. Кроме того, сборки в контексте LoadFrom не могут автоматически использовать преимущества NGen.

Что касается ни одного контекста, сборки в этом контексте не могут быть связаны, если приложение не присоединяется к событию AssemblyResolve. Этот контекст обычно следует избегать.

Так почему же CLR имеет контексты загрузчика в первую очередь? Контексты загрузчика обеспечивают независимость при загрузке при загрузке сборок. Кроме того, они обеспечивают меру изоляции для сборок и их зависимостей, когда они загружаются в разные контексты.

- От Understanding The CLR Binder

Answer 1

Есть, вероятно, лишь немногие люди, которые могут ответить «почему» часть вопроса. Контексты нагрузки в основном связаны с привязкой зависимостей. Я понимаю, что:

• Load, загружает сборку в AppDomain с использованием «традиционных» расположение и методы связывания. Загруженная сборка может использоваться как зависимость для последующих сборок, загружаемых в контексте Load.
• LoadFrom, загружает сборку в AppDomain нахождением зависимостей, таких как Load, но с одной разницей: эти сборки не будут использоваться для разрешения зависимостей Load контекстных сборников.
• LoadNeither загружает только одну сборку. Если у него есть неразрешенные зависимости, вам необходимо решить их самостоятельно с помощью события AssemblyResolve.

Это отличный блог о нем: http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx