Я знаю, что существует 3 разных контекста привязки или контекстов загрузки:
Load
LoadFrom
LoadNeither
- Что такое контексты загрузки?
- Для чего они предназначены?
- Почему загрузка сборки настолько сложна?
- В "LoadNeither", "ни", что?
Спасибо заранее...
--------------- Ниже приведены некоторые полезные цитаты, которые я недавно нашел --------------------
Понять контекст
Никакая статья о Связующем не завершена без адресации контекстов загрузчика и причины их существования. Конфликты загрузчика часто являются источником путаницы. Подумайте о контекстах загрузчика как о логических ведрах в домене приложения, в котором хранятся сборки. В зависимости от того, как загружаются сборки, они попадают в один из трех контекстов загрузчика.
Контекст загрузки. Проще говоря, все сборки, которые присутствуют либо в GAC, либо в ApplicationBase, либо в PrivateBinPath под ApplicationBase, которые загружаются с помощью Assembly.Load, будут загружены в контексте загрузки. Ассембли, разрешенные с использованием события AssemblyResolve, также попадают в эту категорию.
контекст LoadFrom. Если вы пытаетесь загрузить сборку, указав конкретный путь, который находится за пределами ApplicationBase, и сборка не была бы найдена в контексте загрузки, тогда сборка загружается в контекст LoadFrom.
Ни контекст. Если вы пытаетесь загрузить сборку с помощью Assembly.LoadFile(), Assembly.Load(byte []) или Reflection.Emit, эти сборки загружаются в ни один из контекстов.
В случае сборок, загружаемых в контекст LoadFrom, Binder сначала проверяет, присутствует ли точная сборка (такая же идентификация и местоположение) в контексте загрузки. Если это так, он отбрасывает сборку в контексте LoadFrom и использует информацию о сборке из контекста загрузки. При определении того, является ли это одной и той же сборкой, важна информация о местоположении, и мы вскоре рассмотрим ее. В .NET Framework 1.1 это было известно как второе связывание LoadFrom, поскольку Binder использовал для выполнения двух шагов - сначала для размещения сборки в контексте LoadFrom, а затем для ее распространения в контексте загрузки, если он нашел соответствующий идентификатор сборки и местоположение в контексте загрузки.
Убедитесь, что сборка загружена в контекст нагрузки как можно больше. Для этого сборка должна быть локализована из GAC, ApplicationBase или PrivateBinPath из AppDomain. Ассембли, загруженные в этот контекст, автоматически получают преимущества NGen, а зависимости сборки, присутствующие в этом контексте, автоматически подбираются.
Загрузка сборок в контекст LoadFrom имеет свои преимущества: он позволяет загружать несколько сборок вне ApplicationBase, указывая их пути.
Теперь давайте поговорим о местоположении сборки, а также определим, является ли сборка, загруженная через LoadFrom(), такой же, как сборка, загружаемая через Load(). Даже если типы в двух сборках идентичны, если две сборки загружены из разных путей, они не считаются идентичными по отношению к контекстам загрузчика. Это приводит к ситуациям, когда одна и та же сборка повторно загружается в одном домене приложения, но в разные контексты (Load и LoadFrom), а тип в сборке в контексте загрузки не может быть одним и тем же типом в контексте LoadFrom ( даже если они являются одними и теми же сборками в отношении идентификаторов сборки). Это один из недостатков LoadFrom. Кроме того, сборки в контексте LoadFrom не могут автоматически использовать преимущества NGen.
Что касается ни одного контекста, сборки в этом контексте не могут быть связаны, если приложение не присоединяется к событию AssemblyResolve. Этот контекст обычно следует избегать.
Итак, почему CLR имеет контексты загрузчика в первую очередь? Контексты загрузчика обеспечивают независимость при загрузке при загрузке сборок. Кроме того, они обеспечивают меру изоляции для сборок и их зависимостей, когда они загружаются в разные контексты.
