Почему у нас так много способов загрузки сборок?

Question

AFAIK, есть 3 способа загрузки сборки в домен приложения:

• Assembly.Load ()
• Assembly.LoadFrom ()
• Assembly.LoadFile ()

Метод LoadFrom () принимает аргумент filepath сборки в качестве аргумента , но filepath просто предоставляет идентификационную информацию сборки в качестве подсказки для CLR .Метод LoadFrom () все еще внутренне вызывает Load () с этой идентификационной информацией.Так что вполне возможно, что LoadFrom (filepath) загрузит совершенно другую сборку, чем та, которая указана в filepath.Но ручной метод LoadFile () просто загрузит указанную нами сборку.

Мне интересно, зачем нам метод LoadFrom ()?Это не добавляет ничего, кроме путаницы и ловушек.Есть ли сценарий, который применим только LoadFrom ()?

Большое спасибо.

Answer 1

На самом деле существует много дискуссий по этому поводу, с некоторыми различными мнениями:

Разница между LoadFile и LoadFrom для сборок .NET?

http://geekswithblogs.net/rupreet/archive/2010/02/16/137988.aspx

http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/3bdaf65c-520c-4a1a-a825-fc2ca2957bf3

http://blogs.microsoft.co.il/blogs/sasha/archive/2007/03/06/Assembly-Load-Contexts-Subtleties.aspx

Чтобы ответить на ваш вопрос о том, зачем нужен метод LoadFrom (). Ну, похоже, все сводится к желанию загрузить из определенного места и зависимостей. Load () разрешает зависимости, но не позволяет вам выбрать местоположение сборки (т. Е. Существует заданная структура "исследования", в которой пытались найти сборку). LoadFile () гарантирует, что вы загрузите сборку, указанную в качестве строкового параметра, но не разрешает зависимости. LoadFrom () не гарантирует, что сборка, указанная вами в пути, будет загружена (т. Е. Если сборка с аналогичным идентификатором уже загружена), но она разрешает зависимости для вас.

Из MSDN

Используйте метод LoadFile для загрузки и изучить сборки, которые имеют одинаковые идентичности, но расположены в разных пути. LoadFile не загружает файлы в контекст LoadFrom, и делает не разрешать зависимости с помощью путь загрузки, как метод LoadFrom делает. LoadFile полезен в этом ограниченный сценарий, потому что LoadFrom не может быть использован для загрузки сборок, которые имеют одинаковые идентичности, но разные пути; он загрузит только первый такая сборка.

Из того, что я понял, кажется, что шаткое согласие формирует то, что следует держаться подальше от LoadFile (), использовать Load (), если можете, использовать LoadFrom (), если вам нужно. Но я видел, как люди говорили, что держись подальше от LoadFrom ().

В качестве точки данных в стандарте Ecma CLI (http://www.ecma -international.org / публикации / стандарты / Ecma-335.htm ) мы стандартизировали только метод Assembly.Load (string). где строка является именем сборки.

Answer 2

Вы всегда должны использовать Assembly.Load ().Только этот метод может гарантировать предсказуемый результат.Он избегает DLL Hell и гарантирует, что сборка загружается только один раз, даже если код загружает ее более одного раза.

Вам нужны две другие, если вы намеренно нарушаете правила.LoadFrom () используется, если вы хотите загрузить сборку, которая не находится в обычном пути поиска.Довольно распространено для плагинов, например, когда они хранятся в другом каталоге.У вас не возникнет проблем с загрузкой нужной сборки, но у вас do обычно возникает проблема со сборками, от которых она зависит.

LoadFile () делает это тоже, но также ломаетне загружайте его более одного раза ».Это очень, очень редко, это то, что вы хотите.Полезно только в том случае, если вы хотите загрузить копию сборки с той же идентификационной информацией, но сохраненной по другому пути.Какой-то инструмент, который выводит метаданные сборки, например.Избегайте этого во всех других случаях, это не вызывает ничего, кроме страданий.Типы, загруженные из такой сборки, никогда не совместимы с точно такими же типами, загруженными из другой копии сборки.Даже тот же экземпляр.

Answer 3

Он довольно скрыт и не имеет прямого имени, но Assembly.LoadFrom загружает сборку из URI, поэтому вы можете указать нелокальный путь; тогда как Assembly.Load загружается только локально.

Это в комментариях к LoadFrom:

Параметр assemblyFile должен ссылаться на URI без escape-символов. Этот метод предоставляет escape-символы для всех недопустимых символов в URI.

См. MSDN