Цель:

Продолжение изучения служб и обязанностей системы выполнения.

Задачи:

– познакомиться с видами сборок;

– изучить понятие строгого имени сборки;

– разобраться в процедурах загрузке и запуска сборок.

Содержание темы:

Остановимся более подробно на таких функциях системы выполнения, как загрузка сборок и запуск CLR-программ, а для этого вспомним что такое сборка и рассмотрим виды сборок.

Сборка (assembly) – это набор модулей и ресурсов, которые являются частью одной версии приложения и развертываются вместе, а поэтому образуют единый элемент развертывания. Сборки представляют собой основные строительные блоки .NET- приложений.

Сборки обеспечивают многократное использование кода, управление версиями и защиту приложений, а также облегчают их развертывание.

Виды сборок

1) Сборки бывают простыми (состоят только из одного файла (модуля платформы .NET Framework) и сложными (могут включать сразу несколько файлов (модулей и ресурсов)). На рисунке 1 изображена простая сборка.

Рисунок 1 – Простая сборка

2) Различают сборки со встроенным ресурсом (рис.2) и сборки со связанным ресурсом

(рис.3).

Встраивание ресурса – это создание копии файла и физическое включение его в файл сборки. После создания сборки внешний файл ресурса уже не нужен. Во время

выполнения запрос на доступ к файлу будет удовлетворен с помощью копии этого файла, которая уже содержится в сборке (рис.2). 

Рисунок 2. Сборка со встроенным ресурсом

Связывание ресурса – это включение в сборку только имени файла ресурса. В этом случае файл ресурса также является составной частью сборки, но должен развертываться как отдельная ее часть (рис.3).

Рисунок 3. Сборка со связанным ресурсом

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

После связывания внешних ресурсов они становятся полноценными членами сборки, а манифест сборки ссылается на них по именам их файлов. Здесь манифест сборки находится в том же файле, что и модуль, но теперь манифест сборки ссылается (сплошная линия) на файл message.txt. Модуль косвенно ссылается (пунктирная линия) на файл message.txt.

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

библиотеки классов или элементы управления, создают на основе соответствующих шаблонов Visual Studio.

4) Допустимо создавать сборки, содержащие только ресурсы. Такие сборки называют сателлитными. Это удобно, когда ресурсы нужно часто менять, но не хотелось бы перекомпилировать из-за этого все приложение. Сателлитная сборка создается для каждого отдельного регионального стандарта. Нейтральные ресурсы содержатся в основной (или родительской) сборке. Чтобы создать ресурсную сборку, добавляют файл ресурсов в пустой проект. При компоновке такого проекта создается сборка, содержащая исключительно ресурсы, которые можно применять в других сборках, ссылаясь на них в коде.

5) Сборки могут быть закрытыми или разделяемыми (открытыми). Закрытая сборка используется только одним приложением, а разделяемая – доступна нескольким приложениями на данном компьютере. Большинство создаваемых сборок являются закрытыми. Их проще создавать, к тому же по умолчанию создается именно этот тип сборок. Закрытая сборка доступна только одному приложению и является его компонентом, размещается вместе с приложением и доступна только из него. При добавлении в проект ссылки на закрытую сборку, последняя копируется в каталог этого проекта. В связи с этим закрытые сборки не поддерживают управление версиями и расширенные идентификационные данные. В отличие от закрытых сборок, разделяемые сборки существуют на компьютере в единственном экземпляре, который доступен нескольким приложениям. Чтобы сделать сборку разделяемой, необходимо установить ее в кэш глобальных сборок

Подлинность сборки гарантирует строгое имя (strong name). Строгое имя иногда называется также идентификатором сборки (assembly identity). Оно включает идентификационные данные сборки, такие, как ее имя, номер версии, сведения о культуре (информации о региональном стандарте) и открытый ключ из криптографической пары ключей.

Кроме того, сборка может содержать необязательный компонент, а именно: цифровую подпись аутентичности кода (authenticode signature), которая не входит в состав строгого имени.

Таким образом, строгое имя позволяет платформе .NET Framework с абсолютной определенностью предоставить именно ту сборку, которая нужна приложению. Следовательно, концепция строгих имен полностью решает проблему конфликта различных версий DLL-файлов!

Номер версии образует одну из частей строгого имени сборки, поэтому номер версии также образует часть идентификатора сборки. Различные версии одной сборки имеют разные строгие имена (а значит, и разные идентификаторы сборки), поэтому на платформе

.NET Framework они считаются совершенно различными сборками.

При создании собственных сборок платформа .NET Framework записывает полные строгие имена всех упомянутых в них сборок. Эта практика позволяет среде выполнения

.NET Framework получать точную информацию о необходимой версии сборки, а также применять свою политику версий для определения нужной сборки. Используемая по умолчанию политика версий платформы .NET Framework заключается в том, что приложения применяют ту же версию сборки, с помощью которой они создавались и тестировались.

Платформа .NET Framework позволяет различать версии сборок, а не версии приложений. Поэтому одно приложение может косвенно использовать две версии одной сборки.

В .NET исполняемые файлы обслуживаются в отдельном логическом разделе внутри процесса, который называется доменом приложения.

Домены приложений – это подчиненные процессы внутри другого процесса. Процесс является единицей отказоустойчивости внутри операционной системы. Если при выполнении процесса возникает ошибка, например попытка доступа к памяти в адресном пространстве другого процесса, то операционная система прекратит работу ошибочного процесса с сохранением прежнего режима работы остальных процессов.

В единственном процессе может содержаться несколько доменов приложений, каждый из которых обслуживает свой исполняемый файл .NET.

Сборка всегда загружается в домен приложения, обычно в тот, который запрашивает ее. Сборки могут быть нейтральными по отношению к доменам, т.е. код сборки может совместно использоваться всеми доменами приложений.

На рисунке 4 показана упрощенная схема выполняемого СLR-приложения. На ней показано два домена. Каждый домен приложения может содержать одну или несколько сборок. Каждая сборка может содержать один или несколько модулей.

Рисунок 4 – Схема выполняемого CLR-приложения

Потоки не зависят от доменов приложения. Поэтому они могут пересекать границы доменов, а домен приложения может иметь несколько потоков. Разработчики редко непосредственно организуют взаимодействие с доменами приложения, хотя при необходимости такое взаимодействие можно организовать. Для управления доменами приложения разработчики могут использовать класс AppDomain, который содержит базовая платформа Base Framework.

Выполняемая программа в среде CLR содержит следующие компоненты: пользовательскую сборку с точкой входа;

 систему выполнения в файле mscorsvr.dll или файле mscorwks.dll;  базовую систему типов в файле mscorlib.dll.

При запуске CLR-программы всегда должна запускаться среда выполнения. Эту задачу выполняет одна из первых инструкций внутри любого выполняемого CLR-файла, вызывая метод _CorExeMain или метод _CorDllMain, которые находятся в файле mscoree.dll.

Код в файле mscoree.dll определяет, какую версию среды выполнения нужно загрузить. Эта среда располагается в файле mscorsvr.dll (версия для серверов) или файле mscorwks.dll (версия для рабочих станций). Многопроцессорные компьютеры обычно содержат версию для серверов, а все другие компьютеры обычно активизируют версию для рабочих станций.

Выполняемой CLR-программе также часто необходим доступ к типам, определенным в других сборках. Всем CLR-программам нужно получить доступ к определению типа System.Object, поэтому загружается также файл mscorlib.dll.

Среда CLR в метаданных предоставляет информацию не только о типах, но и о сборках, которые являются единицами развертывания на платформе .NET Framework. Как следствие, сборки и типы являются самодокументируемыми. Механизм выполнения использует эту информацию для гарантированного корректного выполнения кода, например с контролем версий.

Сборка содержит несколько модулей, один из которых имеет манифест. Именно добавление такого манифеста к модулю превращает его в сборку.

Модуль – это, по сути, файл, который содержит метаданные CLR. Сборка может содержать CLR-несовместимый файл А. Это не модуль, поэтому он не содержит метаданных CLR, но может содержать ресурсы, используемые типом сборки, например растровые изображения. Манифест содержит такую информацию о сборке, как, например его имя, номер версии, а также имена всех модулей и файлов этой сборки.

Например, две сборки с одинаковым именем и издателем считаются разными, если они отличаются номерами версий. Механизм выполнения позволяет загружать разные версии сборки в выполняемой программе.