ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание
Шрифт:
Сначала мы рассмотрим различия между одномодульными и многомодульными компоновочными блоками, а также между "приватными" и "общедоступными" компоновочными блоками. Затем мы выясним, как среда, выполнений .NET определяет параметры размещения компоновочного блока, и попытаемся понять роль GAC (Global Assembly Cache – глобальный кэш компоновочных блоков), файлов конфигурации приложения (файлы *.config), политики публикации компоновочных блоков и пространства имен System.Configuration.
Роль компоновочных блоков .NET
Приложения .NET строятся путем связывания произвольного числа компоновочных блоков. С
Расширенные возможности многократного использования программного кода
При построений консольных приложений в предыдущих главах могло показаться, что в создаваемом вами выполняемом компоновочном блоке содержатся все функциональные возможности соответствующего приложения. На самом же деле ваши приложения использовали множество типов, предлагаемых всегда доступной библиотекой программного кода .NET, mscorlib.dll (напомним, что компилятор C# ссылается на mscorlib.dll автоматически), а также библиотекой System.Windows.Forms.dll.
Вы, наверное, знаете, что библиотека программного кода (также называемая библиотекой классов) представляет собой файл *.dll, содержащий типы, доступные для использования внешними приложениями. При создании выполняемого компоновочного блока используются компоновочные блоки, предлагаемые системой, а также пользовательские компоновочные блоки. При этом файл библиотеки программного кода не обязательно имеет вид *.dll, поскольку выполняемый компоновочный блок может использовать и типы, определенные во внешнем выполняемом файле. В этой связи файл *.exe тоже можно считать "библиотекой программного кода".
Замечание. До появления Visual Studio 2005 единственную возможность сослаться на выполняемую библиотеку программного кода обеспечивал флаг /reference компилятора C#. Но теперь ссылаться на компоновочные блоки *.exe позволяет и диалоговое окно Add Reference (Добавление ссылки) в Visual Studio 2005.
Независимо от того, как упакована библиотека программного кода, платформа .NET позволяет использовать типы в независимой от языка форме. Например, можно создать библиотеку программного кода в C# и использовать эту библиотеку в любом другом языке программирования .NET. При этом можно не только создавать экземпляры типов в рамках других языков, но и получить производные таких типов. Базовый класс, определенный в C#, можно расширить с помощью класса, созданного в Visual Basic .NET. Интерфейсы, определенные в Pascal .NET, могут реализовываться структурами, определенными в C#. Смысл в том, что при разделении единого и монолитного выполняемого программного кода на множество компоновочных блоков .NET вы получаете языково-нейтральную форму программного кода, пригодного для многократного использования.
Установка четких границ типов
Из главы 3 вы узнали о формальных понятиях, лежащих в основе любого пространства имен .NET. Напомним, что абсолютное имя типа строится путем добавления префикса пространства имен (например, System) к имени типа (например, Console). Однако,
строго говоря, компоновочный блок, содержащий данный тип, задает параметры дальнейшей идентификации типа. Например, если у вас есть два компоновочных блока с разными названиями (скажем, MyCars.dll и YourCars.dll), которые определяют пространство имен (CarLibrary), содержащее класс SportsCar, то эти классы во "вселенной" .NET будут считаться разными типами.Управление версиями
Компоновочным блокам .NET назначается состоящий из четырех частей числовой идентификатор версии, имеющий вид ‹главный номер версии›.‹дополнительный номер версии›.‹номер компоновки›.‹номер варианта› (если вы не укажете явно идентификатор версии с помощью свойства [AssemblyVersion], компоновочный блок автоматически получит идентификатор версии 0.0.0.0). Этот идентификатор в совокупности с необязательным значением открытого ключа позволяет множеству версий одного и того же компоновочного блока сосуществовать на одной и той нее машине в полной гармонии, Компоновочные блоки, обеспечивающие информацию об открытом ключе, называются строго именованными. Как будет показано в этой главе позже, при наличии строго заданного имени среда CLR способна гарантировать, что по запросу вызывающего клиента будет загружена именно та версия компоновочного блока, которая требуется.
Самоописание
Компоновочные блоки считаются единицами с частичным самоописанием, поскольку в них содержится информация о внешних компоновочных блоках, необходимых для правильного функционирования компоновочного блока. Так что если вашему компоновочному блоку требуются System.Windows.Forms.dll и System. Drawing.dll, то информация о них будет записана в манифест компоновочного блока. Вспомните из главы 1, что манифест – это блок метаданных, описывающих сам компоновочный блок (имя, версия, информация о внешних компоновочных блоках и т.д.).
Кроме данных манифеста, компоновочный блок содержит метаданные, описывающие структуру каждого содержащегося типа (имена членов, реализуемые интерфейсы, базовые классы, конструкторы и т.д.). И поскольку компоновочный блок документируется настолько "красноречиво", среда CLR не обращается к реестру системы Win32 для выяснения размещения компоновочного блока (что принципиально отличается от предлагавшейся ранее Microsoft модели программирования COM). Из этой главы вы узнаете, что среда CLR использует совершенно новую схему получения информации о размещении внешних библиотек программного кода.
Средства конфигурации
Компоновочные блоки можно инсталлировать как "приватные" или как "общедоступные". Приватные компоновочные блоки размещаются в том же каталоге (или, возможно, подкаталоге), что и использующее их приложение-клиент. Общедоступные компоновочные блоки, напротив, являются библиотеками, доступными для многих приложений, и такие компоновочные блоки устанавливаются в специальный каталог, имеющий специальное название – глобальный кэш компоновочных блоков (CAG).
Независимо от вида инсталляция компоновочных блоков, вы можете создавать для них XML-файлы конфигурации. С помощью этих файлов можно дать среде CLR "указание" о том, где следует искать компоновочные блоки, какую версию соответствующего компоновочного блока следует загрузить для конкретного клиента, к какому каталогу на локальной машине, в вашей локальной сети или по какому заданному адресу URL в Web следует обратиться. Более подробную информацию о XML-файлах конфигурации вы получите в дальнейшем при изучении материала этой главы.