Теперь вы знаете, что компиляторы .NET Framework генерируют управляемы е модули и что эти модули содержат CIL и метаданные. Однако вас может удивить, что CLR неспособен использовать управляемые модули напрямую. Дело в том, что базовой единицей защиты, управления версиями и развертывания в.NET Framework является не управляемый модуль, а сборка (assembly).
Сборка — это файл или набор файлов, в совокупности составляющих логическую единицу. В данном контексте термином файлы обозначаются главным образом управляемые модули, но в сборку могут входить и иные файлы. Большинство сборок содержит один файл, но может содержать и иногда содержит несколько файлов. Все файлы в составе одной сборки должны находиться в одном каталоге. Когда вы с помощью компилятора С# создаете простой ЕХЕ, то он является не только управляемым модулем, но и сборкой. Большинство компиляторов в состоянии создавать управляемые модули, не являющиеся сборками, а также добавлять другие файлы к сборкам, которые они создают. В состав.NET Framework SDK входит утилита AL (Assembly Linker) для объединения файлов в сборки.
Многофайловые сборки обычно служат для объединения модулей, написанных на разных языках, и для объединения управляемых модулей с обычными файла ми, содержащими изображения в формате JPEG и другие ресурсы, Многофайло вые сборки также применяются для разделения приложений на дискретные загружаемы е части, что может пригодиться в случае развертывания приложения через Интернет. Представьте себе, например, что кто-то пытается загрузить многомегабайтное приложение, состоящее из одного файла-сборки, по коммутируемой телефонной линии, Загрузка такого кода может длиться вечность. Снизить ост роту проблемы могло бы разделение кода на несколько файлов, являющихся частями одной сборки. Так как неиспользуемые модули не загружаются, пользователю не придется ждать окончания загрузки тех частей приложения, которые ему не нужны. Если код приложения удачно разбит на части, загрузка большей его части может вообще никогда не понадобиться.
Как же CLR узнает, какие файлы относятся к сборке? Один из файлов, входящих в сборку содержит декларацию (manifest). Физически декларация — это просто дополнительные метаданные. Когда компилятор создает управляемый модуль, одновременно являющийся и сборкой, декларация просто помещается в метаданные модуля. Логически декларация — это путеводитель по содержимому сборки.
Ее наиболее важные элементы :
• имя сборки;
• список всех остальных файлов сборки вместе с криптографическими хэш-значениями, вычисленными по содержимому файлов;
• список типов данных, экспортируемых другими файлами сборки, и информация, связывающая эти типы данных с файлами, где они определены;
• номер версии в формате major.mmor.build.revision (например, 1.0.3705-0).
Декларация может содержать и другие сведения, в том числе название компании, описание, требуемые права доступа и строку региональных стандартов. Последняя определяет языковые и другие параметры, для которой предназначена эта сборка (например, «en-US» обозначает «United States English»), и обычно используется сателлитными сборками (satellite assemblies), содержащими только ресурсы, На рис. 1-3 изображена многофайловая сборка, состоящая из трех управляемых модулей и файла JPEG. Maiaexe содержит декларацию со ссылками на другие файлы. С точки зрения файловой системы, это по-прежнему отдельные файлы, а с точки зрения CLR — одна логическая единица.
Рис. 1-3. Многофайловая сборка
В отсутствие специальных указаний компиляторы генерируют нестрого именованные (weakly named) сборки. Это значит, что сборка не имеет криптографической подписи и для ее идентификации CLR использует только имя, указанное в декларации (представляющее собой лишь имя файла сборки без расширения). Однако сборки могут быть и строго именованы (strongly named). Такие сборки содержат открытый ключ своего создателя, а также цифровую подпись, являющуюся хэш-зачением, сгенерированным для декларации сборки, в которой хранится открытый ключ.
Цифровая подпись, генерируемая с помощью закрытого ключа создателя сборки, может быть проверена открытым ключом и делает декларацию сборки (а значит, саму сборку) устойчивой к подделкам. Для идентификации строго именованной сборки служат имя сборки, открытый ключ, номер версии и строка региональных стандартов, если она есть. Любое, даже самое малое отличие является достаточным, чтобы отличить две в остальном идентичные сборки.
Для создания строго именованных сборок можно использовать утилиту AL из SDK. Большинство компиляторов, включая С# и Visual Basic.NET, также может генерировать строго именованные сборки. Вы сами принимаете решение, какую сборку — строго или нестрого именованную — использовать. Выбор зависит от назначения сборки. Размещаемая в глобальном кэше сборок (global assembly cache, GAG) — глобальном репозитарии сборок, предназначенных для использования разными приложениями, — сборка должна быть строго именована.
Сборка также должна быть строго именована, если вы хотите использовать контроль версий. При загрузке нестрого именованной сборки CLR не проверяет версию. Это может быть и хорошо, и плохо. Хорошо, если старая версия сборки замещается новой (вероятно, с исправленными ошибками) и приложения, использовавшие эту сборку, должны автоматически начать работать с новой версией. Плохо, если приложение было протестировано для работы с определенной версией сборки, которую затем кто-то заменил на новую, полную ошибок версию. Это один из признаков «ада DLL», столь хорошо знакомого Windows-разработчикам. Строгое именование позволяет его избежать. При загрузке строго именованной сборки CLR сравнивает номер версии загружаемой сборки с тем номером, для которого компилировалось загружающее эту сборку приложение. (Эти сведения хранятся, как можно догадаться, в метаданных модуля.) Если номера не совпадают, CLR генерирует исключение.
Конечно, в строгом контроле версий есть свои ловушки. Допустим, вы решили использовать строгое именование, но затем обнаружили в своей сборке ошибку. Вы исправляете ошибку и распространяете исправленную сборку. Догадались, что произойдет? Приложения, использующие эту сборку, не смогут загрузить новую версию, если их не собрать заново. Они будут по-прежнему загружать старую версию, и если вы ее удалите, то вообще перестанут работать. Решение состоит в изменении политики связывания GLR. Администратор может относительно легко — редактируя конфигурационный файл — перенаправить CLR на новую версию строго именованной сборки. Конечно, если в новой версии есть ошибки, старая проблема возникает снова. Поэтому-то не следует предоставлять административные права всем и каждому.
Процесс работы со сборками выглядит довольно сложным, и иногда так оно и есть. К счастью, если вы не создаете совместно используемые сборки или сборки, связываемые с другим сборками (отличными от FCL, которая, кстати, представляет собой набор совместно используемых сборок), то большинство проблем с именами и связыванием вас не коснется. Вы просто вызываете свой компилятор, копируете получившуюся сборку в нужный каталог и запускаете ее — проще некуда.
Похожие статьи:
