Роль сборок .NET

Приложения.NET создаются за счет складывания вместе некоторого количества

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

обслуживаемый CLR (Common Language Runtime— общеязыковая исполняющая среда).

Хотя сборки.NET имеют точно такие же файловые расширения (*.ехе или *.dll), как и

старые двоичные файлы Win32 (в том числе и унаследованные серверы СОМ), внутри они

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

материла, давайте сначала посмотрим, какие преимущества предоставляет формат сборок.

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

При построении консольных приложений могло показаться, что все функциональные возможности этих приложений содержались внутри создававшейся исполняемой сборки. На самом деле во всех этих приложениях использовались многочисленные типы из всегда доступной библиотеки программного кода.NET по имени mscorlib.dll (напоминаем, что компилятор С# добавляет ссылку на mscorlib.dll автоматически), а в некоторых случаях также и из библиотеки по имени System.Windows.Forms.dll.

Как известно, библиотека кода (также называемая библиотекой классов) представляет собой файл с расширением *.dll, в котором содержатся предназначенные для использования во внешних приложениях типы. При создании исполняемых сборок,

несомненно, придется использовать много системных и специальных библиотек кода

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

"библиотекой кода".

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

типы повторно не зависящим от языка образом. Например, она позволяет не только

размещать типы на различных языках, но производить наследование от них. Базовый

класс, определенный на языке С#, может расширять класс, написанный на языке Visual

Basic. Интерфейсы, определенные в Pascal.NET, могут реализовать структуры,

определенные в С#, и т.д. Главное понять, что разбиение единого монолитного исполняемого файла на несколько сборок.NET открывает возможность использовать код повторно не зависящим от языка образом.

• Сборки определяют границы типов

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

любого пространства имен.NET. Напоминаем, что полностью квалифицированное имя

типа получается за счет добавления к его собственному имени (которое может,

например, выглядеть как Console) в качестве префикса названия того пространства имен,

к которому он относится (которым может быть, например, System). Сборка, в которой

тип находится, далее определяет его сущность. Например, две сборки с уникальными

именами (скажем, MyCars.dll и YourCars.dll), в обеих из которых определяется

пространство имен (CarLibrary), содержащее класс по имени SportsCar, в мире.NET

будут считаться совершенно отдельными типами.

• Сборки являются единицами, поддерживающими версии

Сборкам.NET присваивается состоящий из четырех частей числовой номер версии в

формате <старший номер>.<младишй номер>.<номер сборки>.<номер редакцию* (в

случае не предоставления номера версии явным образом сборке автоматически

присваивается номер 0.0.0.0). Этот номер вместе со значением открытого ключа, которое

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

• Сборки являются самоописываемыми

Сборки считаются самоописываемыми (self-describing) отчасти потому, что содержат

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

того, чтобы функционировать надлежащим образом. Следовательно, если сборке

требуется доступ к библиотекам System.Windows.Forms.dll и System.Drawing.dll, это

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

манифестом называется блок метаданных, которые описывают саму сборку (ее имя, версию, необходимые внешние сборки и т.д.).

Помимо данных манифеста, в сборке еще содержатся метаданные, описывающие

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

интерфейсы, базовые классы, конструкторы и т.п.). Благодаря наличию в самой сборке такого детального описания, CLR-среде не требуется заглядывать в системный реестр для

выяснения ее местонахождения (что радикально отличается от предлагавшейся Microsoft

ранее модели программирования СОМ). Как будет показано далее, вместо этого CLR-

среда использует совершенно новую схему для получения информации о местонахождении внешних библиотек кода.

• Сборки поддаются конфигурированию

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

приложениях на одной и той же машине, и потому развертываются в специальном

каталоге, который называется глобальным кэшем сборок (Global Assembly Cache— GAC).

На рис. 1 показано, как будет выглядеть вывод.

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