Симон Робинсон - C# для профессионалов. Том II

Так как поведение по соединению со сборками может конфигурироваться на основе конфигурационных файла приложения, файла издателя и файла машины/администратора, CLR должна брать эту конфигурационную информацию, чтобы обеспечить извлечение соответствующей версии указанной сборки. Все эти файлы основаны на XML и следуют похожему синтаксису. Они предоставляют такую информацию, как перенаправление связывания, расположение кода и режимы связывания для определенных сборок. Обычно правильная версия сборки определяется некоторой комбинацией трех конфигурационных файлов и собственным манифестом сборки.

CLR сначала проверяет, не переопределяет ли информация конфигурационного файла приложения информацию, которая хранится в манифесте вызывающей сборки. Затем CLR проверяет конфигурационный файл издателя. Этот файл присутствует, только когда приложение было обновлено новыми версиями одного или нескольких компонентов приложения. Это прежде всего используется для переопределения информации в конфигурационном файле приложения, чтобы приложение выбрало новую версию компонента. CLR затем проверяет конфигурационный файл машины/администратора. Хотя он просматривается последним, настройки, присутствующие в этом файле, получают приоритет по отношению ко всем другим конфигурационным настройкам. По сути администраторы используют admin.cfg, чтобы определить ограничения связывания, локальные для данной машины.

Затем CLR необходимо найти сборку. В Java JRE будет действовать в текущем каталоге и в classpass, чтобы найти класс, необходимый для разрешения ссылки. В определении расположения заданной сборки CLR полагается на элемент , связанный с упомянутыми выше конфигурационными файлами. Если такой элемент не предоставлен, то CLR ищет файл (называемый probing) в корневом каталоге приложения, во всех каталогах, перечисленных в конфигурационных файлах элемента и во всех подкаталогах корня приложения, которые имеют такое же имя, как и зондируемая сборка. Эти элементы всегда определяются относительно корневого каталога приложения. Отметим, что CLR всегда ищет имя сборки, соединенное с двумя допустимыми расширениями файлов РЕ — .exeи .dll.

Наконец, если ссылка сделана на сборку с устойчивым именем, CLR будет искать в глобальном кэше сборок. Устойчивые имена и глобальный кэш сборок мы рассмотрим более подробно в следующем разделе.

Устойчивое (строгое) имя делает сборку глобально уникальной. Оно состоит из идентификатора сборки, открытого ключа и цифровой подписи. Так как сборка, созданная с одним открытым ключом имеет другое имя, чем сборка, созданная с другим открытым ключом, то уникальность имени сборки гарантирована. Нельзя изменить сборку с устойчивым именем, не имея доступа к открытому ключу, использованному при ее создании, следовательно, устойчивое имя гарантирует, что никто не сможет создать другие версии этой сборки. Устойчивые имена предоставляют также жесткий контроль целостности. Создание устойчивого имени является двухшаговым процессом. Сначала необходимо создать или иметь ключевую пару. Создание ключевой пары можно выполнить в командной строке с помощью команды:

sn -k <���имя файла ключа>

Например, чтобы создать файл ключа examplekey.key, надо ввести:

sn -k examplekey.key

После создания файл ключа используется для присвоения устойчивого имени сборке двумя способами. Из командной строки можно использовать утилиту alinkследующим образом:

al /keyfile: <���имя файла ключа> <���имя сборки>

Чтобы задать для FirstLibrary.dllстрогое имя, можно выполнить:

al /keyfile:examplekey.key FiretLibrary.dll

или в VS.NET изменить атрибут [assembly: AssemblyKeyFile("")]в файле AssemblyInfo.cs. Замените просто пустую строку на строку, представляющую имя файла ключа. Сборку FirstLibrary.dllможно затем ассоциировать с ключом, меняя атрибут AssemblyKeyFileна [assembly: AssemblyKeyFile("examplekey.key")]. Какой бы метод ни использовался, конечный результат получается тот же самый. CLR будет устанавливать ключ в файл с помощью Crypto Service Provider (CSP). Работа CSP не представлена в данном приложении.

Все сборки в глобальном кэше сборок должны иметь устойчивое имя. Глобальный кэш сборок применяется для хранения сборок, специально созданных для общего использования несколькими приложениями на машине. Существует несколько способов размещения сборки в глобальном кэше сборок. Можно использовать программу установки, созданную для работы с глобальным кэшем сборок, .NET Framework SDK предоставляет программу установки с именем gacutil.exe. Чтобы поместить FirstLibrary.dllв глобальный кэш сборок, воспользуйтесь командой: