Жизнь в многоязычном окружении
В начале процесса осмысления разработчиком языково-агностической природы платформы .NET, у него возникает множество вопросов и прежде всего, следующий: "Если все языки .NET при компиляции преобразуются в "управляемый программный код", то почему существует не один, а множество компиляторов?". Ответить на этот вопрос можно по-разному. Во-первых, мы, программисты, бываем очень привередливы, когда дело касается выбора языка программирования (я здесь тоже не исключение). Некоторые из нас предпочитают языки с многочисленными точками с запятыми и фигурными скобками, но с минимальным набором ключевых слов. Другим нравятся языки, предлагающие более "человеческие" синтаксические лексемы (как Visual Basic .NET). А кто-то не пожелает отказываться от своего опыта работы на большой ЭВМ и захочет перенести его на платформу .NET (используя COBOL .NET).
А теперь скажите честно: если бы Microsoft предложила единственный "официальный" язык .NET, например, на базе семейства BASIC, то все ли программисты были бы рады такому выбору? Или если бы "официальный" язык .NET был основан на синтаксисе Fortran, то сколько людей в мире вообще проигнорировало бы платформу .NET? Поскольку среда выполнения .NET демонстрирует меньшую зависимость от языка, используемого для построения управляемого программного кода, программисты .NET могут, не меняя своих синтаксических предпочтений, обмениваться скомпилированными компоновочными блоками со своими коллегами, другими отделами и внешними организациями (не обращая внимания на то, какой язык .NET используется там).
Еще одно полезное преимущество интеграции различных языков .NET в одном унифицированном программном решении вытекает из того простого факта, что каждый язык программирования имеет свои сильные (а также слабые) стороны. Например, некоторые языки программирования имеют превосходную встроенную поддержку сложных математических вычислений. В других лучше реализованы финансовые или логические вычисления, взаимодействие с центральными компьютерами и т.д. Когда преимущества конкретного языка программирования объединяются с преимуществами платформы .NET, выигрывают все.
Конечно, вы можете разрабатывать программное обеспечение, не выходя за рамки своего любимого языка .NET. Но, изучив синтаксис одного языка .NET, вам будет очень легко освоить любой другой. Это тоже очень выгодно, особенно консультантам. Если вашей специализацией является C#, но вы оказались на узле клиента, который "привязан" к Visual Basic .NET, то сможете почти сразу разобрать соответствующий программный код (поверьте!), воспользовавшись указанным преимуществом .NET. На этом и остановимся.
Независимо от того, какой язык .NET вы выберете для программирования, вы должны понимать, что хотя бинарные .NET-единицы имеют такие же расширения файлов, как COM-серверы и неуправляемые программы Win32 (*.dll или *.exe), их внутреннее устройство совершенно иное. Например, бинарные .NET-единицы *.dll не экспортируют методы для упрощения коммуникации со средой выполнения COM (поскольку .NET – это не COM). Бинарные .NET-единицы не описываются с помощью библиотек COM-типов и не регистрируются в реестре системы. Наверное, самым важным является то, что бинарные .NET-единицы содержат не специфические для платформы инструкции, а независимые от платформы IL-инструкции (Intermediate Language – промежуточный язык) и метаданные типов. На рис. 1.2 это показано схематически.
Рис. 1.2. Все .NET-компиляторы генерируют IL-инструкции и метаданные
Замечание. Относительно сокращения "IL" здесь уместно сказать несколько дополнительных слов. В ходе разработки .NET официальным названием для IL было Microsoft (intermediate Language (MSIL). Однако в вышедшей версии .NET это название было изменено на OIL (Common Intermediate Language – общий промежуточный язык). Поэтому вам следует знать, что в публикациях, посвященных .NET, сокращения IL, MSIL и CIL обозначают одно и то же. В соответствии с терминологией, принятой сегодня, в тексте этой книги используется сокращение CIL.
После создания *.dll или *.exe с помощью подходящего .NET-компилятора, соответствующий модуль упаковывается в компоновочный блок. Подробное описание компоновочных блоков .NET имеется в главе 11. Однако, чтобы продолжить наше обсуждение среды выполнения .NET, вы должны знать основные особенности формата этих новых файлов.
Как уже было сказано, компоновочный блок содержит программный код CIL, который концептуально напоминает байт-код Java в том смысле, что он не компилируется в специфические для соответствующей платформы инструкции, пока это не станет абсолютно необходимо. Обычно "абсолютная необходимость" означает момент, когда на какой-то блок CIL-инструкций (например, реализацию метода) выполняется ссылка для его использования в среде выполнения .NET.
В добавление к CIL-инструкциям, компоновочные блоки также содержат метаданные, которые подробно описывают особенности каждого "типа" внутри данной бинарной .NET-единицы. Например, если вы имеете класс с именем SportsCar, соответствующие метаданные типа будут описывать такие элементы, как базовый класс SportsCar и интерфейсы, реализуемые SportsCar (если таковые имеются), а также содержать полные описания всех членов, поддерживаемых типом SportsCar.
Метаданные .NET более совершенны по сравнению с метаданными COM. Вы, возможно, уже знаете, что бинарные COM-объекты обычно описываются с помощью библиотеки ассоциированных типов, а это почти то же самое, что и бинарная версия IDL-кода (Interface Definition Language – язык определения интерфейса). Проблема использования COM-информации в том, что эта информация не обязательна, и IDL-код не может документировать внешние серверы, которые нужны для правильного функционирования данного COM-сервера. В противоположность этому метаданные .NET присутствуют обязательно и автоматически генерируются соответствующим .NET-компилятором.
Наконец, в добавление к CIL и метаданным типов, сами компоновочные блоки также описываются с помощью метаданных, для которых используют специальное называние манифест (manifest). Манифест содержит информацию о текущей версии компоновочного блока, информацию о "культуре" (используемую для локализации строк и графических ресурсов) и список всех ссылок на внешние компоновочные блоки, которые требуются для правильного функционирования. Из следующих глав вы узнаете о различных инструментах, которые могут использоваться для исследования типов компоновочного блока, расшифровки его метаданных и манифеста.
Одномодульные и многомодульные компоновочные блоки
Во многих случаях компоновочные блоки .NET- это просто файлы двоичного кода (*.dll или *.exe). Поэтому, если вы строите *.dll .NET, можно считать, что файл двоичного кода и компоновочный блок – это одно и то же. Точно также, если вы строите выполняемое приложение для настольной системы, файл *.exe тоже можно считать компоновочным блоком. Но из главы 11 вы узнаете, что указанное соответствие не столь однозначно. Строго говоря, если компоновочный блок состоит из одного модуля *.dll или *.exe, вы имеете одномодульный компоновочный блок. Одномодульный компоновочный блок содержит весь необходимый код CIL, метаданные и манифест в одном автономном отдельном пакете.
Многомодульные компоновочные блоки, в свою очередь, складываются из множества бинарных .NET-единиц, каждая из которых называется модулем. При этом один из таких модулей (он называется первичным модулем) должен содержать манифест компоновочного блока (и может содержать также CIL-инструкции и метаданные различных типов). Остальные связанные модули содержат манифест уровня модуля, CIL и метаданные типов. Как вы можете догадаться, в манифесте первичного модуля компоновочного блока документируется набор необходимых "второстепенных" модулей.
Но зачем создавать многомодульные компоновочные блоки? Когда вы делите компоновочный блок на отдельные модули, вы получаете более гибкие возможности инсталляции. Например, если пользователь ссылается на удаленный компоновочный блок, то среда выполнения загрузит на его машину только необходимые модули. Поэтому вы можете сконструировать свой компоновочный блок так, чтобы редко используемые типы (например, HardDriveReformatter) были выделены в отдельный автономный модуль.
Если все ваши типы размещаются в компоновочном блоке, представляющем собой единый файл, конечному пользователю придется загружать большой набор данных, из которых в действительности могут понадобиться далеко не все (а это, очевидно, означает лишнюю трату времени). Итак, компоновочный блок на самом деле логически сгруппирован в один или несколько модулей, которые должны инсталлироваться и использоваться, как единое целое.
