Net framework 5, а также среды Visual Studio 2012 и C#

638
Глава.23 .Загрузка.сборок.и.отражение
ВниМание
Метод.Load.есть.и.у.объекта.System AppDomain .В.отличие.от.одноименного.метода.
объекта.Assembly,.он.является.экземплярным.методом,.позволяющим.загружать.
сборку.в.домен.приложений .Этот.метод.создан.для.неуправляемого.кода,.позволяя.
хосту.загрузить.сборку.в.определенный.домен.приложений .Разработчикам.управ-
ляемого.кода.лучше.его.избегать,.и.вот.почему .При.вызове.методу.Load.объекта.
AppDomain.передается.строка,.идентифицирующая.сборку .Этот.метод.затем.приме-
няет.политику.и.ищет.сборку.в.обычных.местах:.на.пользовательском.жестком.диске.
или.в.базовом.каталоге .Вспомните,.что.с.каждым.доменом.приложений.связаны.
параметры.конфигурации,.определяющие.правила.поиска.сборки.для.CLR .Так.вот,.
при.загрузке.сборки.CLR.будет.руководствоваться.конфигурацией.заданного,.а.не.
вызывающего.домена.приложений 
Однако.метод.Load.объекта.AppDomain.возвращает.ссылку.на.сборку .В.силу.того,.
что.класс.System Assembly.не.является.потомком.System MarshalByRefObject,.объ-
ект.сборки.возвращается.вызывающему.домену.приложений.путем.продвижения.по.
значению .Но.теперь.для.поиска.и.загрузки.сборки.CLR.задействует.параметры.вы-
зывающего.домена.приложений .Если.сборку.не.удается.найти.при.помощи.политики.
вызывающего.домена.приложений.или.в.заданных.им.каталогах.поиска,.генерируется.
исключение.FileNotFoundException .Такая.ситуация.обычно.нежелательна,.поэтому.
следует.избегать.метода.Load.объекта.System AppDomain 
В большинстве динамически расширяемых приложений метод 
Load
объекта 
AppDomain
является предпочтительным механизмом загрузки сборки в домен при-
ложений, но он требует наличия всех частей, идентифицирующих сборку. Часто 
разработчики создают инструменты или утилиты (такие, как 
ILDasm exe
, 
PEVerify 
exe
, 
CorFlags exe
, 
GACUtil exe
, 
SGen exe
, 
SN exe
и 
XSD exe
), которые определенным 
образом обрабатывают сборку. Все они принимают параметр командной строки, 
задающий путь (с расширением) к файлу сборки.
Чтобы загрузить сборку с указанием пути, вызовите метод 
LoadFrom
класса 
Assembly
:
public class Assembly {
public static Assembly LoadFrom(String path);
// Менее популярные перегруженные версии не показаны
}
Код 
LoadFrom
сначала вызывает метод 
GetAssemblyName
класса 
System.
Reflection.AssemblyName
, который открывает указанный файл, находит запись 
таблицы метаданных 
AssemblyRef
, извлекает идентификационную информацию 
сборки и возвращает ее в объекте 
System.Reflection.AssemblyName
(файл при этом 
закрывается). Затем 
LoadFrom
вызывает метод 
Load
класса 
Assembly
, передавая ему 
объект 
AssemblyName
. На этом этапе CLR применяет политику перенаправления 
версий и ищет в определенных местах соответствующую сборку. Найдя сборку, 
Load
загружает ее и возвращает объект 
Assembly
, представляющий загруженную 
сборку; именно его возвращает 
LoadFrom
. Если методу 
Load
не удается найти сборку, 
LoadFrom
загружает сборку по пути, переданному в качестве параметра в 
LoadFrom
. 

---

639
Загрузка.сборок
Ясно, что если сборка с теми же идентификационными данными уже загружена, 
LoadFrom
просто возвращает объект 
Assembly
, представляющий уже загруженную 
сборку.
Кстати, методу 
LoadFrom
можно передать в качестве параметра URL-адрес:
Assembly a = Assembly.LoadFrom(@"http://Wintellect.com/SomeAssembly.dll");
При получении URL-адреса среда CLR загружает файл, устанавливает его 
в загрузочный кэш пользователя и уже из него загружает файл. Система должна 
быть подключена к Интернету, иначе произойдет исключение. Однако если файл 
уже был загружен в кэш ранее, а браузер Internet Explorer настроен на работу в ав-
тономном режиме (команда 
Work
Offline
(
Работать
автономно
) в меню 
File
(
Файл
)), 
будет использован файл из кэша, и исключение не возникнет. Также можно вызвать 
метод 
UnsafeLoadFrom
, который загрузит уже загруженную веб-сборку, игнорируя 
некоторые параметры защиты.