Читайте также:
|
|
Процесс установки в.NET часто сводится к простому копированию файлов, после чего программа готова к немедленному запуску. Если удалить скопированные файлы, то работать перестает только эта конкретная программа. В этом процессе не используется реестр и не учитываются зависимости между компонентами. Чтобы эта схема нормально работала, в.NET используется концепция сборки.
С технической точки зрения сборка (assembly) в.NET представляет собой минимальную устанавливаемую единицу программного кода. Сборка оформляется в виде автономного ЕХЕ-файла или в виде библиотеки DLL, на которую можно ссылаться из других приложений. Однако сборка содержит нечто большее, чем обычный IL-код, компилируемый и выполняемый исполнительной средой.NET. Как минимум, сборка состоит из одного или нескольких модулей и классов, откомпилированных в IL-код, и метаданных (данных, описывающих данные [Префикс «мета» для подобных абстракций второго порядка позаимствован из метаматематики — области математики, посвященной описанию самих математических объектов.]), которые описывают сборку и функциональность входящих в нее классов. Метаданные являются частью сборки, поэтому в документации сборки названы самодокументируемыми. Во многих ситуациях сборка состоит из одного файла, но встречаются и многофайловые сборки. Например, в сборку могут входить ресурсные файлы, графические изображения и даже дополнительные EXE/DLL-файлы. В любом случае сборка является минимальным объектом.NET, для которого производится контроль версии или задаются привилегии.
В большинстве случаев создаются однофайловые сборки, состоящие из одного ЕХЕ-или DLL-файла.
Сборки бывают закрытыми (private) и общими (shared). Закрытые сборки всегда находятся в каталоге приложения или в одном из его подкаталогов. Общие сборки хранятся в глобальном кэше сборок (GAC, global assembly cache). Начнем с закрытых сборок, поскольку именно они используются по умолчанию для решений, построенных в VS.NET IDE. С общими сборками дело обстоит сложнее, и мы займемся ими позже.
Обычно у закрытых сборок не бывает проблем с несовместимостью версий, однако они требуют дополнительных затрат дискового пространства, если в системе приходится хранить несколько копий одного файла в разных каталогах [В наше время дисковое пространство обходится так дешево, что эти затраты с избытком компенсируются удобствами, связанными с использованием закрытых сборок.]. При создании ссылок на сборку командой Project > Add Reference по умолчанию в каталоге приложения создается новый экземпляр закрытой сборки. Мы рекомендуем по возможности ограничиваться использованием закрытых сборок.
Для управления сборками используются конфигурационные файлы в формате XML. Конфигурационный файл должен находиться в одном каталоге с файлом, содержащим точку входа в сборку. С его помощью можно управлять привилегиями, назначать каталоги для поиска зависимых DLL, а также указывать другие сведения, необходимые для загрузки сборки.
Теоретически сборка может быть устроена весьма сложно, поэтому в нее включается манифест — совокупность всех сведений о сборке, необходимых исполнительной среде (CLR) для загрузки, компиляции (при необходимости) и выполнения сборки. В манифест входят следующие сведения:
- информация, необходимая для поиска модулей, от которых зависит работа сборки;
- имена всех файлов, входящих в сборку;
- имена и метаданные всех сборок и файлов, используемых сборкой;
- данные о версии сборки;
- информация о типах, используемая исполнительной средой для экспортирования типов из сборки (по аналогии с информацией, находящейся в библиотеке типов СОМ).
Именно благодаря наличию манифеста появляется возможность создания сборок, состоящих из нескольких файлов. Кроме того, данные манифеста заменяют сложную систему регистрации компонентов в реестре.
Дата добавления: 2015-01-30; просмотров: 99 | Поможем написать вашу работу | Нарушение авторских прав |