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

C# --- Сборки .NET --- Роль сборок .NET

Приложения .NET создаются за счет складывания вместе некоторого количества сборок. Сборка представляет собой поддерживающий версии самоописываемый двоичный файл, обслуживаемый CLR (Common Language Runtime — общеязыковая исполняющая среда). Хотя сборки .NET имеют точно такие же файловые расширения (*.ехе или *.dll), как и старые двоичные файлы Windows (в том числе и унаследованные серверы СОМ), внутри они устроены совсем иначе. Поэтому прежде чем углубляться в изучение дальнейшего материала, давайте сначала посмотрим, какие преимущества предлагает формат сборок:

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

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

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

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

Базовый класс, определенный на языке C#, может расширять класс, написанный на Visual Basic. Интерфейсы, определенные на языке Pascal .NET, могут реализовать структуры, определенные в C#, и т.д. Главное понять, что разбиение единого монолитного исполняемого файла на несколько сборок .NET открывает возможности для повторного использования кода в не зависящей от языка манере.

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

Полностью уточненное имя типа получается за счет добавления к его собственному имени (которое может, например, выглядеть как Console) в качестве префикса названия пространства имен, к которому тип относится (например, System). Сборка, в которой тип размещен, далее определяет его идентичность. Например, две сборки с уникальными именами (скажем, MyCars.dll и YourCars.dll), в обеих из которых определено пространство имен (CarLibrary), содержащее класс по имени SportsCar, в мире .NET будут считаться совершенно отдельными типами.

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

Сборкам .NET присваивается состоящий из четырех частей числовой номер версии в формате <старший номер>.<младший номер>.<номер сборки>.<номер редакции>. (Если номер версии явно не указан, сборке автоматически назначается номер 1.0.0.0 из-за применяемых по умолчанию в Visual Studio настроек проекта.) Этот номер вместе с необязательным значением открытого ключа позволяет множеству версий одной и той же сборки сосуществовать на одной и той же машине. Формально сборки, в которых предоставляется значение открытого ключа, называются строго именованными. При наличии строгого имени CLR-среда гарантирует загрузку корректной версии сборки от имени вызывающего клиента.

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

Сборки считаются самоописываемыми (self-describing) отчасти потому, что содержат информацию о каждой из внешних сборок, к которой им нужно иметь доступ, чтобы функционировать надлежащим образом. Следовательно, если сборке требуется доступ к библиотекам System.Windows.Forms.dll и System.Drawing.dll, это обязательно будет документировано в ее манифесте.

Помимо данных манифеста, в сборке также содержатся метаданные, которые описывают структуру каждого из имеющихся в ней типов (имена членов, реализуемые интерфейсы, базовые классы, конструкторы и т.п.). Благодаря наличию в самой сборке такого детального описания. CLR-среде не требуется заглядывать в системный реестр Windows для выяснения ее местонахождения (что радикально отличается от предлагавшейся Microsoft ранее модели программирования СОМ).

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

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

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