Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie, которые обеспечивают правильную работу сайта. Благодаря им мы улучшаем сайт!
Принять и закрыть

Читать, слущать книги онлайн бесплатно!

Электронная Литература.

Бесплатная онлайн библиотека.

Читать: ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание - Эндрю Троелсен на бесплатной онлайн библиотеке Э-Лит


Помоги проекту - поделись книгой:

WWW: http://www.williamspublishing.com

Информация для писем из: России: 115419, Москва, а/я 783 Украины: 03150, Киев, а/я 152

ЧАСТЬ I. Общие сведения о языке C# и платформе .NET

ГЛАВА 1. Философия .NET

Каждые несколько лет программист должен быть готов кардинально обновлять свои знания, чтобы идти в ногу с новыми технологиями. Языки (C++, Visual Basic 6.0, Java), каркасы приложений (MFC, ATL, STL) и архитектуры (COM, CORBA, EJB), которые сегодня составляют "золотой фонд" разработки программного обеспечения, в будущем непременно уступят место чему-то более совершенному или, по крайней мере, более новому. Несмотря на разочарование, которое вы можете ощущать при обновлении своей базы знаний, это неизбежно. Платформа .NET - это сегодняшнее предложение Microsoft в области разработки программного обеспечения.

Целью этой главы является построение концептуального фундамента, необходимого для успешного освоения всего остального материала книги. Слава начинается с обсуждения ряда вопросов .NET, относящихся к высокому уровню, – таких как компоновочные блоки, CIL (общий промежуточный язык) и JIT-компиляция (just-in-time – точно к нужному моменту). Вдобавок к вводному обзору некоторых ключевых возможностей языка программирования C#, будет также обозначена взаимосвязь между различными элементами каркаса .NET, такими как CLR (общая языковая среда выполнения), CTS (общая система типов) и CLS (общие спецификации языка). Как вы вправе ожидать, эти темы будут исследоваться более подробно в других частях книги.

Эта глава также содержит обзор возможностей, предлагаемых библиотеками базовых классов .NET, для обозначения которых иногда используют аббревиатуру BCL (Base Class Libraries – библиотеки базовых классов) или, как альтернативу, FCL (Framework Class Libraries – библиотеки каркасных классов). Наконец, в главе обсуждается независимая от языков и платформ сущность платформы .NET (это действительно так - .NET не замыкается на операционной системе Windows).

Предыдущее состояние дел

Перед рассмотрением специфики .NET будет полезно рассмотреть некоторые проблемы, стимулировавшие появление предлагаемой сегодня платформы Microsoft. Чтобы получить соответствующее представление, давайте начнем эту главу с краткого урока истории, чтобы напомнить об истоках и понять ограничения, существовавшие в прошлом (в конце концов, признание существования проблемы является первым шагом на пути ее решения). После этого мы обратим наше внимание на многочисленные преимущества, которые обеспечиваются языком C# и платформой .NET.

Подход C/Win32 API

Традиционно разработка программного обеспечения для операционных систем семейства Windows предполагает использование языка программирования C в сочетании с Windows API (Application Programming Interface – интерфейс программирования приложений). Несмотря на тот факт, что в рамках этого проверенного временем подхода было создано очень много вполне успешных приложений, мало кто станет оспаривать то, что процесс создания приложений непосредственно с помощью API оказывается очень трудоемким делом.

Первая очевидная проблема заключается в том, что C является очень лаконичным языком. Разработчики программ на языке C вынуждены "вручную" управлять памятью, использовать безобразную арифметику указателей и ужасные синтаксические конструкции. К тому же, поскольку C является структурным языком программирования, ему не хватает преимуществ, обеспечиваемых объектно-ориентированным подходом (здесь можно вспомнить о "макаронных" программах). Когда вы объединяете тысячи глобальных функций и типов данных, определенных в рамках Win32 API, с языком, который и без того выглядит устрашающе, не следует удивляться тому, что среди используемых сегодня программ оказывается так много ненадежных.

Подход C++/MFC

Огромным шагом вперед по сравнению с подходом, предполагающим использование C/API, явился переход к применению языка программирования C++. Во многих отношениях язык C++ можно рассматривать, как объектно-ориентированную надстройку над C. Поэтому, хотя при использовании C++ уже можно использовать преимущества известных "краеугольных камней ООП" (инкапсуляция, наследование и полиморфизм), этот подход оставляет программиста во власти многих болезненных аспектов языка C (управление памятью "вручную", безобразная арифметика указателей и ужасные синтаксические конструкции).

Несмотря на сложность, сегодня существует множество каркасов программирования на C++. Например, MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) снабжает разработчика набором C++-классов, упрощающих создание Win32-приложений. Главной задачей MFC является представление "разумного подмножества" Win32 API в виде набора классов, "магических" макросов и средств автоматического генерирования программного кода (обычно называемых мастерами). Несмотря на очевидную пользу указанного каркаса приложений (как и многих других средств разработчика, использующих C++), программирование на C++ остается трудной задачей, и на этом пути нелегко полностью избежать ошибок ввиду "тяжелой наследственности", обусловленной связью с языком C.

Подход Visual Basic 6.0

Благодаря искреннему желанию насладиться более простой жизнью, многие программисты ушли от "мира каркасов" приложений на базе C(++) к более дружественным языкам, таким, как, например, Visual Basic 6.0 (VB6). Язык VB6 стал популярным благодаря тому, что он дает возможность строить сложные интерфейсы пользователя, библиотеки программного кода (например, COM-серверы) и системы доступа к данным, затрачивая минимум усилий. В сравнении с MFC, VB6 еще глубже скрывает от глаз разработчика сложность Win32 API, используя для этого целый ряд интегрированных мастеров, внутренних типов данных, классов и специфических для VB функций.

Главным недостатком VB6 (который был устранен в Visual Basic .NET) является то, что VB6 является, скорее, "объектно-осведомленным" языком, а не полноценным объектно-ориентированным. Например, в VB6 программисту не позволяется связывать типы отношениями "подчиненности" (т.е. нет классического наследования) и нет внутренней поддержки конструкции параметризованных классов. Кроме того, VB6 не дает возможности строить многопоточные приложения, если только вы не готовы "спуститься" до низкоуровневых вызовов Win32 API (что в лучшем случае достаточно сложно, а в худшем – опасно).

Подход Java/J2EE

Было предложено использовать Java. Язык программирования Java является (почти) полностью объектно-ориентированным и имеет синтаксические корни в C++. Многие знают, что поддержка межплатформенной независимости – далеко не единственное преимущество Java. Java (как язык) избавлен от многих синтаксических несообразностей C++. Java (как платформа) предлагает программисту большое число встроенных "пакетов", содержащих различные определения типов. С помощью этих типов, используя "только Java", можно строить приложения, предлагающие сложный интерфейс пользователя, обеспечивающие связь с базами данных, обмен сообщениями или работу клиента в Web.

Хотя Java – очень элегантный язык, его потенциальной проблемой является то, что использование Java в цикле разработки обычно означает необходимость использования Java и для взаимодействия клиента с сервером. Как следствие, Java не позволяет возлагать большой надежды на возможности языковой интеграции, так как это идет вразрез с декларируемой целью Java (единый язык программирования для всех задач). Реальность, однако, такова, что в мире существуют миллионы строк программного кода, которым бы идеально подошло взаимодействие с более новым программным кодом. К сожалению, Java делает эту задачу проблематичной.

Java в чистом виде просто не подходит для многих приложений, интенсивно использующих графику или сложные вычисления (в этих случаях скорость работы Java оставляет желать лучшего). Для таких программ в соответствующем месте выгоднее использовать язык более низкого уровня (например, C++). Увы, пока Java не обеспечивает более широкие возможности доступа к "чужеродным" API, истинная интеграция различных языков оказывается практически невозможной.

Подход COM

Модель COM (Component Object Model – модель компонентных объектов) была предыдущим каркасом разработки приложений Microsoft. По сути, COM – это архитектура, "заявившая" следующее: если класс будет построен в соответствии с правилами COM, то получится блок двоичного кода многократного использования.

Прелесть двоичного COM-сервера в том, что способ доступа к нему не зависит от языка. Поэтому программисты, использующие C++, могут строить COM-классы, пригодные для использования в VB6. Программисты, применяющие Delphi, могут использовать COM-классы, построенные с помощью C, и т.д. Однако, и вы, возможно, об этом знаете, независимость COM от языка несколько ограничена. Например, нет возможности получить новый COM-класс из уже существующего (поскольку COM не предлагает поддержки классического наследования). Вместо этого для использования типов COM-класса вам придется указать несколько неуклюжее отношение "обладания".

Еще одним преимуществом COM является прозрачность дислокации. Используя такие конструкции, как идентификаторы приложения (AppID), "заглушки" и "заместители" в среде выполнения COM, программист может избежать необходимости непосредственного обращения к сокетам, RPC-вызовам и другими низкоуровневым элементам. Рассмотрим, например, следующий программный код VB6 COM-клиента.

' Этот блок программного кода VB6 может активизировать COM-класс,

' созданный на любом языке, поддерживающем COM, и размещенный

' в любой точке сети (включая вашу локальную машину).

Dim с as MyCOMClass

Set с = New MyCOMClass ' Размещение выясняется с помощью AppID.

с.DoSomeWork

Хотя COM можно считать очень успешной объектной моделью, внутренне она чрезвычайно сложна (по крайней мере, пока вы не потратите несколько месяцев на изучение ее внутренних механизмов – особенно если вы программируете на C++). С целью упрощения процесса разработки бинарных COM-объектов было создано множество каркасов разработки приложений с поддержкой COM. Среди них, например, библиотека ATL (Active Template Library – библиотека активных шаблонов), которая обеспечивает еще одно множество C++-классов, шаблонов и макросов, упрощающих создание COM-типов.

Многие другие языки также в значительной степени скрывают инфраструктуру COM от глаз программиста. Однако поддержки самого языка оказывается недостаточно для того, чтобы скрыть всю сложность COM. Даже при использовании относительно простого совместимого с COM языка (например, VB6), вы все равно вынуждены бороться с "хрупкими" параметрами регистрации и многочисленными проблемами, связанными с инсталляцией приложений (в совокупности называемыми "кошмаром DLL").

Подход Windows DNA

Ко всем указанным выше сложностям еще добавляется такая мелочь, как Интернет. За последние несколько лет Microsoft добавила в свое семейство операционных систем и других продуктов множество связанных с Интернет возможностей. К сожалению, создание Web-приложений в рамках совместимой с COM архитектуры Windows DNA (Distributed interNet Applications Architecture – архитектура распределенных сетевых приложений) также оказывается очень непростым делом.

Некоторая доля этой сложности вытекает из того простого факта, что Windows DNA требует использования множества технологий и языков (ASP, HTML, XML, JavaScript, VBScript, а также COM(+) и API доступа к данным, например ADO).

Одной из проблем является то, что с синтаксической точки зрения многие из этих технологий совершенно не связаны одна с другой. Например, в JavaScript используется синтаксис, во многом подобный C, a VBScript является подмножеством VB6. COM-серверы, созданные для работы в среде выполнения COM+, по виду сильно отличаются от ASP-страниц, которые их вызывают. Результат – чрезвычайно запутанная смесь технологий.

К тому же, и это, возможно, самое важное, каждый язык и каждая технология имеют свои собственные системы типов (которые могут быть совершенно не похожими одна на другую). Например, нельзя сказать, что "int" в JavaScript и "Integer" в VB6 означают в точности одно и то же.

Решение .NET

Слишком много для короткого урока истории. Основным выводом является то, что жизнь программиста Windows была трудна. Каркас .NET Framework является достаточно радикальной "силовой" попыткой сделать нашу жизнь легче. Решение, предложенное .NET, предполагает "изменить все" (извините, вы не можете обвинять посыльного за такое известие). Вы поймете из дальнейшего материала книги, что .NET Framework – это совершенно новая модель для создания систем как в семействе операционных систем Windows, так и множестве операционных систем, отличных от систем Microsoft, таких как Mac OS X и различные варианты Unix/ Linux. Чтобы это продемонстрировать, вот вам краткий список некоторых базовых возможностей, обеспечиваемых .NET.

Полноценная возможность взаимодействия с существующим программным кодом. Это (конечно) хорошо. Существующие бинарные COM-объекты могут комбинироваться (т.е. взаимодействовать) с более новыми бинарными .NET-объектами и наоборот. Кроме того, сервисы PInvoke (Platform Invocation Services – сервисы вызова платформ) позволяют вызывать библиотеки на базе C (включая API операционной системы) из программного кода .NET.

Полная и тотальная интеграция языков. В отличие от COM, платформа .NET поддерживает межъязыковое наследование, межъязыковую обработку исключений и межъязыковую отладку.

Общий механизм выполнения программ для всех языков с поддержкой .NET. Одной из особенностей этого механизма является четкий набор типов, "понятных" каждому языку.

Библиотека базовых классов. Эта библиотека позволяет избежать сложностей прямого обращения к API и предлагает согласованную объектную модель, используемую всеми языками с поддержкой .NET.

Отсутствие детализации COM. В собственном бинарном .NET-объекте небудет места для IClassFactory, IUnknown, IDispatch, IDL-кода и "злобных" типов данных наподобие VARIANT (BSTR, SAFEARRAY и т.д.).

Упрощенная модель инсталляции. Согласно спецификациям .NET, нет необходимости регистрировать соответствующую бинарную единицу в реестре системы. К тому же .NET вполне допускает существование множества версий одного *.dll на одной машине.

На основе информации этого списка вы, вероятно, уже сами пришли к заключению, что платформа .NET не имеет ничего общего с COM (за исключением того, что оба эти каркаса разработки приложений исходят из Microsoft). Фактически единственным способом взаимодействия типов .NET и COM оказывается использование возможностей слоя взаимодействия.

Замечание. Описание возможностей слоя взаимодействия .NET (включая Plnvoke) выходит за рамки этой книги. Если вам потребуется подробное освещение этого вопроса, обратитесь к моей книге COM and .NET Interoperability (Apress, 2002).

Главные компоненты платформы .NET (CLR, CTS и CLS)

Теперь, когда вы знаете о некоторых преимуществах, обеспечиваемых .NET, давайте рассмотрим три ключевых (и взаимосвязанных) компонента, которые и обеспечивают эти преимущества: CLR, CTS и CLS. С точки зрения программиста .NET может интерпретироваться как новая среда выполнения программ и всеобъемлющая библиотека базовых классов. Слой среды выполнения здесь называется CLR (Common Language Runtime – общеязыковая среда выполнения). Главной задачей CLR являются размещение, загрузка и управление .NET-типами по вашему указанию. Кроме того, CLR отвечает за ряд низкоуровневых вопросов, таких, как, например, управление памятью и проверка безопасности.

Другим строительным блоком платформы.NET является CTS (Common Type System – общая система типов). Спецификации CTS полностью описывают все возможные типы данных и программные конструкции, поддерживаемые средой выполнения, указывают, как эти элементы могут взаимодействовать друг с другом и как они представляются в формате метаданных .NET (более подробная информация о метаданных будет представлена немного позже).

Вы должны понимать, что конкретный язык, совместимый с .NET, может и не поддерживать абсолютно все возможности, определенные CTS. В связи с этим используются связанные спецификации CLS (Common Language Specification – общеязыковые спецификации), которые определяют подмножество общих типов и программных конструкций, понятных всем языкам программирования, совместимым с .NET. Поэтому, если создаваемые вами .NET-типы опираются только на возможности, соответствующие CLS, вы можете пребывать в уверенности, что использовать их сможет любой совместимый с .NET язык. А если вы используете типы данных или программные конструкции, выходящие за пределы CLS, вы не можете гарантировать, что с вашей библиотекой программного .NET-кода сможет взаимодействовать любой язык программирования .NET.

Роль библиотек базовых классов

В дополнение к спецификациям CLR и CTS/CLS, платформа .NET предлагает библиотеку базовых классов, доступную всем языкам программирования .NET. Эта библиотека базовых классов не только инкапсулирует различные примитивы, такие как потоки, файловый ввод-вывод, визуализация графики и взаимодействие с различными внешними устройствами, но и обеспечивает поддержку целого ряда сервисов, необходимых для большинства современных приложений.

Например, библиотеки базовых классов определяют типы, упрощающие доступ к базам данных, работу с XML, поддержку программной безопасности и создание Web-приложений (а также обычных настольных и консольных приложений) клиента. Схема высокоуровневых взаимосвязей между CLR, CTS, CLS и библиотекой базовых классов показана на рис. 1.1.


Рис. 1.1. CLR, CTS, CLS и библиотека базовых классов

Роль языка C#

С учетом того, что принципы .NET так радикально отличаются от предшествующих технологий, Microsoft разработала новый язык программирования, C# (произносится "си-диез"), специально для использования с этой новой платформой. Язык C# является языком программирования, по синтаксису очень похожим на Java (но не идентичным ему). Однако называть C# "переработанным" вариантом Java будет неверно. C#, как и Java, основан на синтаксических конструкциях C++. Так же, как и Java, C# можно называть "рафинированной" версией C++ – в конце концов, это языки одного семейства.

Многие синтаксические конструкции C# построены с учетом решений, принятых в Visual Basic 6.0 и C++. Например, как и в VB6, в C# поддерживаются формальные свойства типов (в противоположность традиционным методам get и set) и возможность объявления методов с переменным числом аргументов (через массивы параметров). Подобно C++, в C# позволяется перегрузка операций, а также создание структур, перечней и функций обратного вызова (посредством делегатов).

Благодаря тому, что C# является гибридом множества языков, он является продуктом, который синтаксически так же "чист", как Java (если не "чище"), почти так же прост, как VB6, и обладает почти такой же мощью и гибкостью, как C++ (без соответствующих "ужасных" конструкций). По сути, язык C# предлагает следующие возможности (многие из которых присущи и всем другим языкам программирования, обеспечивающим поддержку .NET).

• Не требуется никаких указателей! Программы на C# обычно не требуют прямого обращения к указателям (хотя имеется возможность получить к ним доступ на более низком уровне, если вы сочтете это абсолютно необходимым).

• Автоматическое управление памятью через сборку мусора. По этой причине в C# не поддерживается ключевое слово delete.

• Формальные синтаксические конструкции для перечней, структур и свойств классов.

• Аналогичная C++ перегрузка операций для пользовательских типов, но без лишних сложностей (например, вам не требуется контролировать "возвращение *this для связывания").

• В C# 2005 имеется возможность строить общие типы и общие члены с использованием синтаксиса, очень похожего на шаблоны C++.

• Полная поддержка техники программирования, основанной на использовании интерфейсов.

• Полная поддержка технологии аспектно-ориентированного программирования (АОП) через атрибуты. Эта ветвь разработки позволяет назначать характеристики типам и их членам, чтобы уточнять их поведение.

Возможно, самым важным для правильного понимания языка C#, поставляемого Microsoft в связке с платформой .NET, является то, что получаемый с помощью C# программный код может выполняться только в среде выполнения .NET (вы не сможете использовать C# для построения "классического" COM-сервера или автономного приложения Win32 API). Официальный термин, который используется для описания программного кода, предназначенного для среды выполнения .NET, – управляемый программный код (managed code). Бинарный объект, содержащий такой управляемый программный код, называется компоновочным блоком (подробнее о компоновочных блоках мы поговорим немного позже). С другой стороны, программный код, который не может непосредственно управляться средой выполнения .NET, называется неуправляемым программным кодом (unmanaged code).

Другие языки программирования с поддержкой .NET

Вы должны понимать, что C# является не единственным языком, ориентированным на платформу .NET. Когда платформа .NET была впервые представлена общественности на Профессиональной конференции разработчиков Microsoft в 2000 году, ряд производителей объявили, что они уже разрабатывают версии соответствующих компиляторов, совместимые с .NET. На момент создания этой книги десятки различных языков подверглись влиянию .NET. В дополнение к пяти языкам, которые предлагаются в Visual Studio 2005 (C#, J#, Visual Basic .NET, Managed Extensions для C++ и JScript .NET), имеются также .NET-компиляторы для Smalltalk, COBOL и Pascal (это далеко не полный перечень).

Материал этой книги почти исключительно посвящен языку C#, но в табл. 1.1 приводится список других языков программирования, совместимых с .NET, и указано, где найти более подробную информацию о них (учтите, что соответствующие адреса URL могут измениться).

Таблица 1.1. Некоторые из языков программирования, совместимых с .NET

Адрес Web-страницы языка .NET Описание
http://www.oberon.ethz.ch/oberon.NET "Домашняя" страница Active Oberon .NET
http://www.usafa.af.mil/df/dfcs/bios/mcc_html/a_sharp.cfm " Домашняя" страница А# (порт Ada для платформы .NET)
http://www.netcobol.com Для тех, кого интересует COBOL .NET
http://www.eiffel.com Для тех, кого интересует Eiffel .NET
http://www.dataman.ro/dforth Для тех, кого интересует Forth .NET
http://www.silverfrost.com/ll/ftn95/ftn95_fortran_95_for_windows.asp Для тех, кого интересует Fortran .NET
http://www.vmx-net.com Оказывается, доступен даже Smalltalk .NET

Следует учесть, что информация табл. 1.1 не является исчерпывающей. Списки компиляторов для .NET имеются на многих Web-узлах, и один из таких списков должен быть на странице http://www.dotnetpowered.com/languages.aspx (опять же, точный адрес URL может измениться). Я рекомендую посетить эту страницу, поскольку вас непременно заинтересуют хотя бы некоторые из языков .NET (может, кому-то понадобится LISP .NET).

Жизнь в многоязычном окружении

В начале процесса осмысления разработчиком языково-агностической природы платформы .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 вы выберете для программирования, вы должны понимать, что хотя бинарные .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) были выделены в отдельный автономный модуль.

Если все ваши типы размещаются в компоновочном блоке, представляющем собой единый файл, конечному пользователю придется загружать большой набор данных, из которых в действительности могут понадобиться далеко не все (а это, очевидно, означает лишнюю трату времени). Итак, компоновочный блок на самом деле логически сгруппирован в один или несколько модулей, которые должны инсталлироваться и использоваться, как единое целое.

Роль CIL

Теперь, когда вы имеете начальное представление о компоновочных блоках .NET, давайте немного подробнее обсудим роль общего промежуточного языка (CIL). CIL- это язык, находящийся выше любого набора инструкций, специфического для конкретной платформы. Независимо от того, какой язык .NET вы выберете для использования, соответствующий компилятор сгенерирует инструкции CIL. Например, следующий программный код C# моделирует тривиальный калькулятор. Не пытаясь пока что полностью понять синтаксис этого примера, обратите внимание на формат метода Add() в классе Calc.

// Calc.cs

using System;



Поделиться книгой:

На главную
Назад