Управляемые модули, MSIL код и метаданные

Возможности исполняющей среды CLR доступны разным языкам программирования. Если CLR использует исключения для обработки ошибок, то во всех языках можно получать сообщения об ошибках посредством исключений. Если исполняющая среда позволяет создавать поток, во всех языках могут создаваться потоки. Фактически во время выполнения CLR не знает, на каком языке написан исходный код. А значит, при разработке приложений следует выбирать язык, позволяющий решить задачу простейшим способом. Писать код можно на любом языке, компилятор которого предназначен для CLR (под компиляцией подразумевается контроль синтаксиса и анализ «корректного кода»). У различных языков синтаксис различается. Компиляторы проверяют исходный код, убеждаются, что все написанное имеет какой-то смысл, и затем генерируют код, описывающий решение задачи. Microsoft предлагает компиляторы для нескольких языков, предназначенных для этой платформы: C++/CLI, С#, Visual Basic, F#, Iron Piton, Iron Ruby и ассемблер Intermediate Language (IL). Кроме Microsoft еще несколько компаний создали компиляторы, генерирующие код, работающий в CLR. Это компиляторы для Ada, APL, Caml, COBOL, Eiffel, Forth, Fortran, Haskell, Lexico, LISP, LOGO, Lua, Mercury, ML, Mondrian, Oberon, Pascal, Perl, Php, Prolog, Python, RPG, Scheme, Smalltalk и Tcl/Tk.

Создавать файлы с исходным кодом можно на любом языке, поддерживающем CLR, соответствующий компилятор проверяет синтаксис и анализирует исходный код. Независимо от компилятора результатом является управляемый модуль (managed module) – стандартный переносимый исполняемый (portable executable, РЕ) файл 32-разрядной (РЕ32) или 64-разрядной Windows (PE32+), требующий для своего выполнения CLR.

Рис. 1.

Все CLR-совместимые компиляторы генерируют IL-код (или MSIL-код, Microsoft Intermediate Language-код) (Рис. 1). IL-код иногда называют управляемым (managed code), потому что CLR управляет его жизненным циклом и выполнением. Каждый компилятор, предназначенный для CLR, кроме генерации IL-кода, создает полные метаданные (metadata) для каждого управляемого модуля. Метаданные – это набор таблиц данных, описывающих все, что определено в модуле, например, типы и их члены. В метаданных также есть таблицы, указывающие, на что ссылается управляемый модуль, например, на импортируемые типы и их члены. Метаданные расширяют возможности таких старых технологий, как библиотеки, при этом они гораздо полнее. В отличие от библиотек типов метаданные всегда связаны с файлом, содержащим IL-код. Фактически метаданные всегда встроены в тот же.exe/.dll файл, что и код, поэтому их нельзя разделить. Так как компилятор генерирует метаданные и код одновременно и привязывает их к конечному управляемому модулю, рассинхронизация метаданных и описываемого ими IL-кода исключена.

Метаданные служат многим целям.

· Они устраняют необходимость в заголовочных и библиотечных файлах при компиляции, поскольку все сведения о типах/членах, на которые есть ссылки, содержатся в файле с IL-кодом, в котором они реализованы. Компиляторы могут читать метаданные прямо из управляемых модулей.

· Visual Studio.NET использует метаданные для облегчения написания кода. Функция IntelliSense анализирует метаданные и сообщает, какие методы предлагает тип и какие параметры требуются этим методам.

· В процессе верификации кода CLR использует метаданные, чтобы убедиться, что код совершает только «безопасные» операции.

· Метаданные позволяют сериализовать поля объекта в блок памяти на удаленной машине и затем десериализовать, восстановив объект и его состояние на этой машине.

· Метаданные позволяют сборщику мусора отслеживать жизненный цикл объектов. Используя метаданные, сборщик мусора определяет тип объектов и узнает, какие поля в них ссылаются на другие объекты.

1.3. Visual C#

CLR запускает исполняемый код, создаваемый с помощью компилятора. Можно создавать приложения для платформы.NET Framework с использованием любого языка, компилятор которого может генерировать исполняемый код в формате, распознаваемом CLR. Visual Studio 2010 предоставляет компиляторы для C++, Visual Basic, F# и C#. Компиляторы для других языков доступны от различных сторонних поставщиков.

C# является языком многих разработчиков. Он использует синтаксис, очень похожий на сиснаткис языков C, C++ и Java, а также имеет несколько расширений и особенностей, предназначенных для работы с.NET Framework. В силу его «родственности» с другими языками программирования многие разработчики находят язык C# простым в обучении и быстрым в производительности.

Ниже приведен неполный список ключевых функциональных возможностей языка С#, присутствующих во всех его версиях.

· Не требуется использовать никаких указателей. В программах на С# обычно не возникает необходимости в манипулировании указателями напрямую (хотя такая возможность существует).

· Управление памятью осуществляется автоматически посредством сборки мусора. По этой причине ключевое слово delete в С# не поддерживается.

· Предлагаются формальные синтаксические конструкции для классов, интерфейсов, структур, перечислений и делегатов.

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

· Предлагается поддержка для программирования с использованием атрибутов. Такой подход в сфере разработки позволяет снабжать типы и их члены аннотациями и тем самым еще больше уточнять их поведение.

С выходом версии.NET 2.0 (2005 г.), язык программирования С# был обновлен и стал поддерживать многочисленные новые функциональные возможности, наиболее значительные из которых перечислены ниже.

· Возможность создавать обобщенные типы и обобщенные элементы-члены. За счет применения обобщений можно создавать очень эффективный и безопасный для типов код с многочисленными метками-заполнителями, подстановка значений в которые происходит в момент непосредственного взаимодействия с обобщенным элементом.

· Поддержка для анонимных методов, которые позволяют предоставлять встраиваемую функцию везде, где требуется использовать тип делегата.

· Многочисленные упрощения в модели «делегат-событие», в том числе возможность применения ковариантности, контравариантности и преобразования групп методов.

· Возможность определять один тип в нескольких файлах кода (или, если необходимо, в виде представления в памяти) с помощью ключевого слова partial.

В версии.NET 3.5 (2008 г.) в язык программирования С# снова были добавлены новые функциональные возможности, наиболее важными из которых являются следующие.

· Поддержка для строго типизированных запросов (также называемых запросами LINQ), применяемых для взаимодействия с различными видами данных.

· Поддержка для анонимных типов, позволяющих моделировать форму типа, а не его поведение.

· Возможность расширять функциональные возможности существующего типа с помощью методов расширения.

· Возможность использовать лямбда-операцию (=>), которая еще больше упрощает работу с типами делегатов в.NET.

· Новый синтаксис для инициализации объектов, позволяющий устанавливать значения свойств во время создания объектов.

В текущем выпуске платформы.NET версии 4.0 (2010 г.) язык С# был опять обновлен и дополнен рядом новых функциональных возможностей. Хотя приведенный ниже перечень новых конструкций может показаться довольно ограниченным, но в ряде случаев они могут оказаться очень полезными.

· Поддержка необязательных (опциональных) параметров, а также именованных аргументов в методах.

· Поддержка динамического поиска членов во время выполнения посредством ключевого слова dynamic. Эта поддержка предоставляет в распоряжение универсальный подход для осуществления вызова членов «на лету», с помощью какой бы платформы они не были реализованы (COM, IronRuby, IronPython, HTML DOM или службы рефлексии.NET).

· Вместе с предыдущей возможностью в.NET 4.0 значительно упрощается обеспечение взаимодействия приложений на С# с унаследованными серверами СОМ, благодаря устранению зависимости от сборок взаимодействия (interop assemblies) и предоставлению поддержки необязательных аргументов ref.

· Работа с обобщенными типами стала гораздо понятнее, благодаря появлению возможности легко отображать обобщенные данные на и из общих коллекций System.Object с помощью ковариантности и контравариантности.

C# язык был стандартизирован и описывается спецификацией языка C# ECMA-334 (4-е издание, июнь 2006). Некоторые производители, кроме Microsoft, разрабатывают компиляторы C#. Реализация от Microsoft называется Visual C# и интегрируется в Visual Studio, который поддерживает Visual C# с полнофункциональным редактором кода, компилятором, шаблонами проектов, дизайнерами, мастером кода, мощным и простым в использовании отладчиком и другими инструментами. C# также доступен как Visual C# Express Edition, и обеспечивает набор функций, которые предоставляются с Visual Studio.

C# представляет собой развивающийся язык. Visual C# 2010 использует версию C# 4.0, которая содержит несколько расширений для языка C#, которые еще не входят в стандарт ECMA.

http://msdn.microsoft.com/en-gb/library/kx37x362(v=vs.110).aspx

 

http://msdn.microsoft.com/en-us/library/bb383815(v=vs.100).aspx

Сборки в.NET

Сборка (assembly) – это абстрактное понятие. Во-первых, это логическая группировка одного или нескольких управляемых модулей и файлов ресурсов. Во-вторых, это самая маленькая единица с точки зрения повторного использования, безопасности и управления версиями. Сборка может состоять из одного (однофайловая сборка) или нескольких (многофайловая сборка) файлов – все зависит от выбранных средств и компиляторов. В мире.NET сборка представляет собой то, что в других условиях называют компонентом. Управляемые модули и файлы ресурсов (или данных) объединяются инструментальным средством, которое и формирует единственный PE-файл, представляющий логическую группировку файлов. При этом PE-файл содержит блок данных, называемый декларацией или манифестом (manifest). Манифест – один из наборов таблиц в метаданных. Эти таблицы описывают файлы, которые формируют сборку, общедоступные экспортируемые типы, реализованные в файлах сборки, а также относящиеся к сборке файлы ресурсов или данных. Если сборка является набором нескольких файлов, один из файлов сборки выбирают для хранения ее манифеста. По умолчанию компиляторы сами выполняют работу по превращению созданного управляемого модуля в сборку, то есть компилятор С# создает управляемый модуль с манифестом, указывающим, что сборка состоит только из одного файла. Итак, в проектах, где есть только один управляемый модуль и нет файлов ресурсов (или данных), сборка и будет управляемым модулем, и не нужно прилагать дополнительных усилий по компоновке приложения. Если же надо сгруппировать набор файлов в сборку, потребуются дополнительные инструменты (вроде компоновщика сборок AL.exe) с соответствующими параметрами командной строки (Рис. 2).

Рис. 2.

Сборка позволяет разделить логический и физический аспекты компонента, поддерживающего повторное использование, безопасность и управление версиями. Разбиение кода и ресурсов на разные файлы отдано полностью на откуп разработчика. Так, редко используемые типы и ресурсы можно вынести в отдельные файлы сборки. Отдельные файлы могут загружаться из интернета по мере надобности. Если файлы никогда не потребуются, они не будут загружаться, что сохранит место на жестком диске и ускорит установку. Сборки позволяют разбить на части процесс развертывания файлов и в то же время рассматривать все файлы как единый набор. Модули сборки также содержат сведения о других сборках, на которые они ссылаются (в том числе номера версий). Эти данные делают сборку самоописываемой (self-describing). Иначе говоря, CLR знает о сборке все, что нужно для ее выполнения. Поэтому развертывать сборки гораздо проще, чем неуправляемые компоненты.

CLR работает со сборками – сначала всегда загружает файл с манифестом, а затем получает из манифеста имена остальных файлов сборки. Некоторые характеристики особенно важны:

· в сборке определены повторно используемые типы;

· сборка помечена номером версии;

· со сборкой может быть связана информация безопасности.

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

Хотя использование локальных сборок имеет свои преимущества, иногда необходимо сделать сборку общедоступной. До появления платформы.NET доминировал подход, при котором код общих библиотек помещался в системный каталог простым копированием фалов при установке. Такой подход привел к проблеме, известной как «ад DLL» (DLL Hell). Инсталлируемое приложение могло заменить общую библиотеку новой версией, при этом другие приложения, ориентированные на старую версию библиотеки, переставали работать. Для устранения «ада DLL» в платформе.NET используется специальное защищенное хранилище сборок (Global Assembly Cache, GAC).

Сборки, помещаемые в GAC, должны удовлетворять определенным условиям. Во-первых, такие глобальные сборки должны иметь цифровую подпись. Это исключает подмену сборок злоумышленниками. Во-вторых, для глобальных сборок отслеживаются версии и языковые культуры. Допустимой является ситуация, когда в GAC находятся разные версии одной и той же сборки, используемые разными приложениями.

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

NameAssembly,Version=1.1.0.0,Culture=en,PublicKeyToken=874e23ab874e23ab

Номер версии сборки состоит из следующих компонент:

· Главного номера версии (Major version number)

· Второстепенного номера версии (Minor version number)

· Номера сборки (Build number)

· Номера версии (Revision number)

Часть Major является обязательной. Любая другая часть может быть опущена (в этом случае она полагается равной нулю). Часть Revision можно задать как *, тогда компилятор генерирует ее как количество секунд, прошедших с полуночи, деленное на два. Часть Build также можно задать как *. Тогда для нее будет использовано количество дней, прошедших с 1 февраля 2000 года.

Как правило, когда сборка представляется клиентам как часть приложения, следует убедится, что она содержит информацию о версии, и что сборка подписана (signed). Управление версиями сборок важно, поскольку, в конечном счете, все строящиеся приложения будут иметь несколько выпусков (releases). Информация о версии сможет помочь определить, какие версии у клиентов уже есть, и позволит выполнять необходимые действия по обновлению приложений. Аналогичным образом информация о версии также может помочь при документировании и исправление ошибок. Подписание сборки важно, потому что оно гарантирует, что сборка не может быть легко изменена или заменена альтернативной реализацией от злоумышленников, и так как дает сборке строгое имя. Такая информация, как версия сборки и идентичность безопасности хранятся, как и метаданные, в манифесте сборки. Манифест также содержит метаданные, описывающие сферу сборки и любые ссылки на классы и ресурсы.

Подписание сборки (Assembly Signing) является важным шагом, который должен включаться в процесс разработки, поскольку это обеспечивает следующие преимущества:

· Защищает сборки от модификаций.

· Позволяет включать подписанную сборку в глобальный кэш сборок (GAC), позволяя ее использовать другим приложениям.

· Гарантирует, что имя сборки является уникальным.

Для подписи сборки строгим именем необходимо иметь пару ключей – открытый и закрытый. Эта пара открытого и закрытого ключей шифрования используется в процессе компиляции для создания сборки со строгим именем. Пару ключей можно создать с помощью инструмента для работы со строгими именами (Sn.exe). Файлы пары ключей обычно имеют расширение.snk. С помощью следующей команды создается новая пара случайных ключей, которая сохраняется в файле keyPair.snk.

sn -k keyPair.snk

Параметр -k указывает на создание ключей. Следующая команда отображает открытый ключ и его маркер, которые содержатся в файле keyPair.snk.

sn -tp keyPair.snk

Если необходима отложенная подпись сборки и имеется контроль над всей парой ключей, для создания пары ключей и получения из нее открытого ключа для записи его в отдельный файл можно использовать следующие команды. Сначала создается пара ключей:

sn -k keyPair.snk

Затем выполняется извлечение открытого ключа из пары и копирование его в отдельный файл:

sn -p keyPair.snk publicKey.snk

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

Для подписи сборки строгим именем, можно использовать компоновщик сборок (Assembly Linker, Al.exe)), входящий в пакет SDK для Windows, специальные атрибуты уровня сборки [AssemblyKeyFile] или [AssemblyKeyName] (в зависимости от того, где находится используемый файл ключа) либо использовать ключ компилятора командной строки /keyfile.

После подписания сборку можно поместить в GAC. Для этого можно использовать утилиту gacutil.exe, входящую в состав.NET Framework SDK. При использовании ключа /i сборка помещается в GAC, а ключ /u удаляет сборку из GAC:

gacutil.exe /i NameAssambly.dll

В результате сборка с именем NameAssambly будет помещена в GAC, при этом ее сильное имя (для ссылки в программах) будет иметь вид:

NameAssambly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ff8e56aa9648cb91

Если необходимо указать версию сборки, используется атрибут [AssemblyVersion].

http://go.microsoft.com/fwlink/?LinkId=192879

http://go.microsoft.com/fwlink/?LinkId=192880

http://go.microsoft.com/fwlink/?LinkId=192881