Модули .NET
Модулем в .NET называется выполняемая программа (или ее некоторая часть),
поставляемая в виде отдельного блока. Модули — это средства для создания паке-
тов программ на С# для выполнения и распространения. Когда вы строите про-
грамму на С#, то получаемый в результате файл с расширением . ехе представляет
собой не что иное как модуль. Если вы строите библиотеку классов, то получае-
мый в результате файл DLL (Dynamic Link Library — динамически загружаемая
библиотека) также представляет собой модуль.
Весь код, находящийся в некотором модуле, строится, распространяется
и получает номер версии как единое целое. Модуль экспортирует общие классы,
свойства и методы, доступные для Других программ. Все объекты, описанные
как частные, остаются внутренними для модуля. Для получения более подробной
информации следует продолжить чтение книги. Для получения дополнительной
информации вам можно осуществить поиск по доступной в режиме онлайн
документации .NET Framework для термина "Assembly" (модуль).
Хотя все программы на С# упаковываются в виде модулей, многие возможно-
сти модулей разработаны таким образом, чтобы упростить распространение про-
грамм в виде специального класса, который называется компонентом. Понимание
компонентов оказывается существенным для понимания тех преимуществ, которое
дает использование модулей.
Компоненты
Компонентом называется некоторая подпрограмма или часть программы, которая
предназначается для использования другой программой. Кроме того, компонент
представляет собой блок в двоичном виде (т. е. выполняемый код, а не исходный
текст), который может использоваться другими программами без необходимости
повторной компиляции как самого компонента, так и программы, использующей
этот компонент. Это означает, что от сторонних производителей не требуется пре-
доставлять исходный код для своих компонентов.
Слово "компонент" может быть определено различными способами. В самом
общем смысле этот термин описывает произвольную подпрограмму, представлен-
ную в двоичном виде; при таком использовании этого термина любая DLL по
определению является компонентом, поскольку она представляет собой подпрог-
рамму, содержащую выполняемый код.
Более строгое определение налагает требование, гласящее, что компонент должен
обладать средствами, которые позволяют ему объявлять о собственном содержи-
мом другим программам. В рамках .NET все модули обладают такими средствами
объявления.
588 Глава 21
Наиболее строгое определение компонента требует, чтобы компонент обладал
определенными интерфейсами, позволяющими освобождать не используемые более
системные ресурсы, и поддерживал интеграцию с инструментами, использующимися
для разработки. В рамках .NET Framework компонент в таком строгом смысле
ЭТОГО СЛОВа ДОЛЖен Обладать интерфейсом Syst em. ComponentModel. IComponent, KO-
торый обеспечивает реализацию указанных возможностей.
Для того чтобы понять преимущества модулей, мы будем пользоваться менее
строгим определением, которое включает в себя налагаемое на компонент требо-
вание объявления о собственном содержимом.
Преимущества компонентов
Компоненты обеспечивают улучшенные возможности повторного использова-
ния и гибкость, а также упрощают распространение подпрограмм. Повторное ис-
пользование программ, представленных в двоичном виде, экономит время
и повышает надежность.
Представьте себе класс shapes (фигуры), в котором находятся различные объ-
екты, представляющие окружности, треугольники и другие геометрические фигуры.
В нем могут содержаться методы, предназначенные для 'подсчета площади фигур
или для выполнения каких-либо других операций над фигурами. Класс shapes мо-
жет использоваться программами из самых разных областей: рисования/создания
графических объектов, разработки технических, архитектурных и строительных
чертежей, проектирования с использованием компьютера, а также игровыми
и другими программами.
Было бы замечательно, если бы можно было описать подпрограммы, предназ-
наченные для рисования и выполнения различных манипуляций над фигурами,
только один раз, а потом использовать их во всех перечисленных программах.
Именно в этом и заключается преимущество повторно используемого кода.
Многократное использование без необходимости каждый раз проходить компи-
ляцию и настройку ссылок для каждой из использующих этот класс программ по-
зволило бы сэкономить большое количество времени и привело бы к увеличению
надежности (поскольку при выполнении процедур повторной компиляции и на-
стройки ссылок всегда существует вероятность внесения ошибок).
Более того, возможно какой-то другой программист или компания уже создали
некоторый компонент класса shapes, который выполняет необходимые вам опера-
ции; в этом случае вы сможете воспользоваться этим компонентом (переписав
и/или купив его), и вам не придется создавать его самому. Раз существует воз-
можность обеспечения общего доступа к компонентам, представленным в двоич-
ном виде, то не придется беспокоиться о том, какой язык программирования был
использован при создании данного компонента. .NET Framework и ее модули по-
зволяют пользоваться всеми этими преимуществами.
Краткая история компонентов
Для того чтобы обладать возможностью многократно использовать компонен-
ты, представленные в двоичном виде, должен существовать некий стандарт, опре-
деляющий способ, который будет использоваться при именовании и применении
объектов на двоичном уровне. Такой стандарт для продуктов, работающих в среде
Microsoft, со временем претерпевал определенные изменения.
В Microsoft Windows было введено понятие DLL, что позволило одной или не-
скольким программам использовать блок кода, хранящийся в виде отдельного файла.
Модули .NET 589
Все это работало на довольно примитивном уровне — только^ в том случае, если
все программы были написаны на одном и том же языке программирования (обыч-
но на С). При этом программы должны были обладать большим количеством пред-
варительной информации об используемой DLL, а сами DLL не позволяли
программам обмениваться своей информацией.
Для обмена данными между программами была разработана система DDE
(Dynamic Data Exchange — динамический обмен данными). В ней определялся
формат и механизм передачи данных от одной программы другой, но этой системе
не хватало гибкости. Вслед за ней появилась система OLE 1.0 (Object Linking and
Embedding — загрузка и встраивание объектов), которая обеспечивала реальную
возможность документу из одной программы (например, Excel) входить в состав
другого документа (например, документа Word). Это уже в некотором смысле на-
поминало компоненты, хотя на самом деле OLE 1.0 не представляла собой настоя-
щий многофункциональный стандарт компонента.
В середине 90-х компания Microsoft описала свой первый стандарт компонента
в стандарте COM (Component Object Model — объектная модель компонента),
реализованного в среде Windows. OLE версии 2 и множество появившихся впо-
следствии технологий были построены на основе СОМ. В DCOM (Distributed
СОМ — распределенная СОМ) была введена возможность, позволяющая СОМ-
компонентам взаимодействовать в сети, а в СОМ+ добавились службы, которые
могли вызываться компонентами для обеспечения высокого быстродействия в сре-
де многозвенных приложений.
СОМ работает неплохо, однако она оказывается очень сложной для изучения
и использования (в особенности, если она используется из C + + ). СОМ налагает
требование включать информацию о компонентах в системный реестр Windows,
что значительно усложняет инсталляцию компонентов и затрудняет их удаление.
Изначально СОМ разрабатывалась для использования с C/C + + ; она была
расширена таким образом, чтобы Visual Basic мог использовать ее ("Automation",
автоматизация), и все это на самом деле работало замечательно, хотя в результате
программистам, работающим на C/C + + , стало даже труднее добиваться совмес-
тимости компонентов с Visual Basic (так, например, по-прежнему отсутствовала
возможность осуществлять наследование от класса, описанного на другом языке
программирования).
Ко всему прочему, по мере того как пользователи начали инсталлировать раз-
личные версии DLL и СОМ-компонентов, созданные компанией Microsoft и други-
ми производителями, стали возникать проблемы, поскольку разные программы
использовали разные версии одной и той же DLL общего доступа. Оказалось, что
одной программе не составляет никакого труда инсталлировать другую версию
той DLL, которая уже используется какой-либо иной программой, что приводило
к нарушению работы этой программы (это явление получило название "ад DLL").
Необходимость отслеживать всю информацию о различных DLL, инсталлирован-
ных на одной системе, существенно затрудняло процесс обновления и сопровожде-
ния компонентов.
В модели программирования .NET определяется новый стандарт, призванный
решить эти проблемы.
Самоописание
Наиболее важным аспектом модулей .NET, отличающим их от всех своих пред-
шественников, является их полная самоописательность. Описание содержится
внутри самого модуля, поэтому системе или вызывающей программе не требуется
590 Глава 21
обращаться к реестру или куда-либо еще за информацией относительно содержа-
щихся в модуле объектов.
Самоописание в модулях .NET выходит далеко за рамки простого описания
имен объектов и методов, а также типов данных, использующихся в качестве пара-
метров; в модулях кроме того содержится информация о том, какова версия дан-
ного объекта (представьте себе Shapes 1.0, за которым следует Shapes 1.1 или
Shapes 2.0), и обеспечивается безопасное использование содержащихся в них объ-
ектов. Вся эта информация содержится непосредственно внутри самого модуля,
поэтому нет никакой необходимости осуществлять поиск этой информации где-
либо еще. В результате этого инсталляция .NET-компонентов становится намного
более простой и понятной процедурой по сравнению со всеми предшествующими
технологиями Windows. Она может быть сведена к простому копированию модулей
на диск в системе, для которой они предназначены.
Модули .NET и библиотека классов JET Framework
Каждой программой в .NET, включая программы на С#, широко используется
библиотека классов .NET Framework. Эти классы используются каждый раз, когда
вызывается какой-либо метод из пространства имен System с помощью директивы
using System — все Пространства имен System (System.Data, System.Drawing
и т. д.) входят в состав библиотеки классов .NET Framework.
Каждый класс, входящий в состав этой библиотеки, представляет собой часть
самоописывающегося модуля. Классы, предназначенные, например, для рисова-
ния, содержатся в модуле system.Drawing.dll. Если, работая в Visual Studio.NET,
вы включите ссылку на этот модуль, то компилятор включит эту ссылку в модуль,
который он будет строить для вашей программы. Система выполнения про-
грамм — CLR — считывает метаданные из модуля вашей программы, для того
чтобы извлечь информацию относительно тех модулей, которые ей требуются,
а затем осуществляет поиск и загрузку этих модулей для использования их вашей
программой. Модули, на которые ссылается ваша программа, могут, в свою оче-
редь, ссылаться на другие модули, поэтому даже самая простая программа, в кото-
рой используется единственная директива using, может ссылаться на несколько
различных модулей. Самоописание каждого модуля отслеживает все эти ссылки,
поэтому от вас не требуется даже знать о них.
Здесь необходимо внести определенную ясность, с тем чтобы
избежать путаницы в дальнейшем. Пространства имен и модули
не всегда в точности соответствуют друг другу. Так, например,
в модуле system.Data.dll реализованы некоторые программы,
одновременно принадлежащие пространствам имен system.Data
и system.xmi, хотя другие программы из пространства имен
System.Xml реализованы в модуле System.Xml.dll.
Внутри программы с помощью директивы using вы ссылаетесь
на пространство имен; ссылки в проекте Visual Studio.NET
определяют конкретные используемые модули.
Одновременное использование
разных языков программирования
Дополнительное преимущество модулей и всей системы .NET заключается
в возможности одновременно использовать различные языки программирования,
поскольку компоненты могут вызываться из любого языка программирования,
Модули .NET 591
включенного в .NET, независимо от того, на каком языке этот компонент был из-
начально написан.
В .NET имеется несколько особенностей, которые делают возможным одновре-
менное использование нескольких различных языков программирования:
• Common Language Runtime (CLR — единый язык выполнения программ),
который управляет выполнением всех модулей в .NET.
• MSIL (Microsoft Intermediate Language — промежуточный язык
компании Microsoft), который генерируется компиляторами со всех
языков программирования, включенных в .NET. Он представляет собой
единый стандарт двоичного кода, генерируемого компиляторами,
и именно он выполняется CLR. В CLR также определяется формат,
в котором хранятся метаданные модулей, а это означает, что для хранения
метаданных во всех модулях используется единый формат независимо
от того, на каком языке этот модуль разрабатывался.
. • Common Language Specification (CLS — единая спецификация языков
программирования), которая устроена таким образом, что программы,
написанные на С#, Visual Basic, C++ или любых других CLS-совместимых
языках программирования .NET, могут получать общий доступ
к компонентам с наследованием, выходящим за рамки отдельного языка.
В CLS определяются возможности, которые должны поддерживаться
языками для обеспечения их совместного использования друг с другом.
Существует возможность использовать и другие особенности языков
программирования, не входящие в CLS, но в этом случае отсутствует
гарантия того, что эти особенности поддерживаются в других языках.
• Common Type System (CTS — единая система типов), которая определяет
базовые типы, используемые в языках программирования .NET
и правила определения программистами своих собственных классов.
Это позволяет избегать реализации типа string недопустимым образом.
Следуя CLS-спецификации, вы можете написать на С# некоторый компонент,
а модуль, в котором этот компонент содержится, может быть использован из про-
граммы, написанной на другом языке программирования .NET, таком как Visual
Basic.NET, поскольку оба компонента — и С#, и VB.NET — будут выполняться
CLR. В программах, написанных на С#, могут использоваться компоненты, напи-
санные на VB.NET, Managed C++ и т. д. На уровне модулей все классы, объекты
и типы данных могут совместно использоваться всеми языками программирования
.NET, поэтому классы могут наследоваться, а компоненты полноценно использо-
ваться независимо от того, на каком языке программирования они написаны.
Самоописывающиеся модули для СОМ
и другого унаследованного кода
.NET Framework также допускает использование с С# и другими языками про-
граммирования .NET компонентов и библиотек, написанных с использованием СОхЭД
и других "унаследованных" технологий.
Этот механизм также предполагает использование самоописывающихся модулей;
на самом деле при этом происходит создание модуля, который охватывает достав-
шийся по наследству код; такой модуль представляет .NET собственное описание,
преобразовывает типы данных СОМ в типы данных .NET и обеспечивает возможность
вызывать унаследованный код из языков программирования .NET и наоборот.
592 Глава 21
Модуль
.NET-клиента
В Visual Studio.NET происходит автоматическое создание охватывающего модуля
в тот момент, когда вы включаете ссылку на СОМ-компонент (посредством вклад-
ки СОМ в диалоге Add Reference).
На приведенной ниже диаграмме изображен такой охватывающий модуль
(который также называют вызываемой оболочкой периода выполнения). Вызовы
такого модуля, осуществляемые .NET-клиентом, проходят через оболочку, прежде
чем достигают самого СОМ-компонента; с точ-
ки зрения модуля .NET охватывающий модуль
представляет собой обычный компонент.
Охватывающий
модуль . СОМ-Компонееннт)
Структура модулей
Манифест
(метаданные модуля)
Метаданные типов
MSIL-код
Ресурсы
(при необходимости)
Ссылки
на другие
модули
Отдельные части модуля обеспечивают для программ в .NET возможность на-
ходить друг друга и раскрывать ссылки программ и компонентов друг на друга.
В модуле выполняемый код программы или библиотеки классов хранится со-
вместно с метаданными (данными, описывающими другие данные), которые по-
зволяют другим программам находить классы, методы и свойства объектов,
определяемые в рамках данного модуля. Метаданные выступают в двух ипостасях:
в виде оглавления, в котором описывается содержимое данного модуля, и в виде
библиографии, где описываются ссылки на различные данные, находящиеся вне
модуля. Давайте рассмотрим этот вопрос более подробно.
Модули .NET, состоящие из одного файла,
обладают общим форматом, представленном
на рисунке справа.
В каждом модуле содержится манифест,
где описывается содержимое данного модуля.
Манифест также называется метаданными
модуля, поскольку он описывает собственный
модуль — что в нем содержится, на какие
другие модули он ссылается и т. д. Манифест
модуля будет подробно рассматриваться ниже
в этой главе, когда будет изучаться содержи-
мое созданного модуля. Предыдущие технологии с использованием компонентов,
такие как СОМ, не имели встроенных объектов, аналогичных манифесту; мани-
фест — это ядро самоописания, содержащееся в модулях .NET.
Система выполнения программ .NET использует манифест, содержащийся в мо-
дуле программы, для раскрытия ссылок на другие модули, имеющиеся в системе,
например, на библиотеку System.Console, В КОТОрОЙ содержится метод WriteLine () ,
позволяющий вывести "Hello, World!".
За манифестом следуют метаданные типов — описание классов, свойств, ме-
тодов и т. п., которые содержатся в модуле наряду с описанием типов данных, ис-
лользуемых ими параметров и возвращаемых значений. Далее следует собственно
двоичный код для каждого типа, хранящийся в виде машиннонезависимого кода на
языке Microsoft Intermediate Language (MSIL — промежуточный язык компании
Microsoft). Наконец, следует еще одна часть модуля — ресурсы, представляющие
собой невыполняемые части программы (представлен-
ные в виде файлов с расширением .Resources), напри-
мер, файлы с рисунками, иконками или сообщениями.
Хотя часто модуль состоит только из одного файла,
он также может быть составлен из нескольких файлов,
как показано на рисунке слева.
Манифест
Метаданные типов
MSIL-код
\
Метаданные типов
MSIL-код
Ресурсы
Модули .NET 593
С точки зрения системы выполнения программ .NET модуль, состоящий из не-
скольких файлов, представляет собой единую логическую DLL или ЕХЕ, которая
состоит из нескольких файлов. Только один файл содержит манифест, в котором
помещаются ссылки на остальные файлы, входящие в состав данного модуля. Фай-
лы, в которых хранится выполняемый код, называются отсеками, в них находятся
метаданные типов и MSIL-код. Кроме того, в наличии могут быть еще файлы ре-
сурсов, содержащие невыполняемый код.
Модули, состоящие из нескольких файлов, обычно используются только в не-
которых очень сложных приложениях. Отдельный отсек или ресурс загружается
только в тот момент, когда он реально начинает выполняться или использоваться,
поэтому, когда редко используемые отсеки и ресурсы хранятся в виде отдельных
файлов, удается сократить время, затрачиваемое на загрузку, и занимаемую
память. Например, некое приложение, используемое в различных странах, может
обладать какими-либо отсеками или ресурсами, написанными на различных нацио-
нальных языках; такие отсеки или ресурсы должны выделяться в отдельные файлы,
с тем чтобы в действительности в память загружался только отсек с фактически
используемым локальным языком.
Создание модулей
Теперь попробуем создать модуль и познакомимся с его свойствами. Сначала
потребуется создать простую библиотеку классов на С#, на которую мы будем
ссылаться на протяжении оставшейся части данной главы. Мы создадим упрощен-
ную версию компонента shapes, который был упомянут в начале главы.
PfOj&{JdtJ ТУР ФV*y;ioj Bos - r" ejects
О Visual C# Projects
;'•• Ш Visual C++- Projects
Г • H i 5etup and Deployment Projects
t, D Other Projects
Cl Visual Studio Solutions
j Shdpss
Создание
библиотеки классов
Воспользуйтесь Visual Studio.NET
и создайте проект библиотеки классов
shapes (см. рис. справа).
Переименуйте файл ciassi.es, со-
здаваемый ПО умолчанию, В shapes.es
и введите в него исходный код, приве-
денный ниже. Двоичный файл, который
будет создан на основе файла shapes.es,
получит название shapes.dll и будет
использоваться в качестве примера
модуля.
Исходный код для Shapes
Исходный код на С# для модуля shapes.dll имеет следующий вид:
namespace Shapes
public class Circle
:••"•••.-.••.•.•. dOUble RadiUS; ;'•••'• • •:•••••:••:-•,•-•••:::.:•: .:' : :
Templates:
Windows Ы&Я1Ш5Ф Windows
Application Control Library §
Ш
ASPJCTW«b ASP.METWeb Web Control
Application Service Library
praSpFor creating t t e ^ ' ^ t t h e r ^ t i k ^ -
Name:
Location:
zl
: p\Cbapter21
Project wil be created ^t C:\BegCSharp\Chapter21\5h5pes.
594 Глава 21
public Circle()
{
Radius ~ 0;
public Circle(double givenRadius)
Radius = givenRadius;
: • i;:.-::: - ] ': • r -:-!.';" :-,." •..':: "•:; ^:: ;• •"":.-- •'" .' -;;:-:":-:.. v"-:" -.: ;.:""::= :
::.x-" ••.••":.:
--!: •:":•:;"-: • j::;i:":":::t;.:" ;.i";:::; !?:;:i-"^ :,\: -":":': -:-':::': •;•""" . -,.' .-:• ;:.="•.
public double Area() •• .
{
// площадь равняется числу к, умноженному ка квадрат радиуса
return System.Math.PI * (Radius * Radius);
}
:::::;:;V..-:-;;;:;v•:•;'-•:'• >-;;^V.i:;:;>'^^-•;•;;::;••• "H;!.;^ vv">:v=i':::;::;:;:.->\.::-;.-л;/;-:'-j-;!;:;!; У":^;;^::^--:
:" •: /•••;•- -•• лг";:"-:;:.-•' • ^:-.•-•:;:• ^-:-:'-:::i• !•-^-:-:-:>::.:;"-';:'-:;''•••^-public class Triangle
'{
double Base; (Заглавная буква В используется здесь с целью избежать
путаницы с -ключевым словом base.— Прим. пер.)
double Height;
public Triangle()
{
Base = 0;
Height = 0;
}
public Triangle(double givenBase, double givenHeight)
{ • •: • " • • • '
Base = givenBase;
Height = givenHeight; v : : /
public double Area()
— : . • ' { , , Л - •••• •• "^
return 0.5F * Base * Height; // площадь равняется одной второй
// произведения основания на высоту
Этот код является очень простым, и в нем не реализованы все возможности,
которые могут потребоваться при работе с геометрическими фигурами, но для на-
ших целей этого вполне достаточно. Единственная хитрость заключается в том, что
каждый класс —• и circle (окружность), и Triangle (треугольник) — обладает
двумя конструкторами, одному из которых вообще не требуются параметры, а дру-
гому параметры необходимы для инициализации экземпляров переменных. Мы вер-
немся к этому вопросу позднее, при изучении модулей.
Компиляция библиотеки классов
При использовании Visual Studio.NET для построения проекта shapes следует
выбрать опцию Build | Build (Ctrl-Shift-B).
Если вы используете компилятор С# из командной строки, то файл shapes.cs
следует откомпилировать с помощью следующей команды:
esc /target:library shapes.cs
Модули .NET 595
Это приведет к созданию файла с именем shapes.dll в текущей директории.
Опция /target:library указывает компилятору на необходимость создания требу-
емого модуля в виде DLL, а не в виде выполняемого файла (с расширением . ехе).
Если возникли проблемы с выполнением команды esc
из командной строки, то это может являться
следствием неверного значения переменной среды PATH.
Правильная настройка этой переменной описывается
в приложении А.
Просмотр содержимого модуля
Tool
ОШСОМ Object &V$ewer ActiveX C&ntrot 7'ost Cc&ntas
Просмотрим содержимое только что созданного модуля shapes.dll с использо-
ванием описания, содержащегося внутри него. В качестве инструмента для про-
смотра содержимого модуля будет использоваться ildasm (Intermediate Language
DisASseMbler tool — инструмент для дезассемблирования промежуточного языка).
Это очень удобный инструмент, предназначенный для просмотра внутренней струк-
туры модулей в доступном представлении. Однако, вам вряд ли придется использо-
вать его при повседневной разработке программ на С#, поэтому запоминать
детали его использования совершенно необязательно