Общеязыковая спецификация CLS

 

Как известно, в разных языках программирования одни и те же программные конструкции выражаются своим уникальным, специфическим для конкретного языка образом. Например, в С# конкатенация строк обозначается с помощью знака «плюс» (+), а в Visual Basic для этого обычно используется амперсанд (&). Даже в случае выражения в двух отличных языках одной и той же программной идиомы (например, функции, не возвращающей значения), очень высока вероятность того, что с виду синтаксис будет выглядеть очень по-разному.

Как уже показывалось, подобные небольшие вариации в синтаксисе для исполняющей среды .NET являются несущественными благодаря тому, что соответствующие компиляторы (в данном случае — csc.exe для C# и vbc.exe для VB) генерируют схожий набор CIL-инструкций. Однако языки могут еще отличаться и по общему уровню функциональных возможностей. Например, в каком-то из языков.NET может быть или не быть ключевого слова для представления данных без знака, а также поддерживаться или не поддерживаться типы указателей. Из-за всех таких вот возможных вариаций было бы просто замечательно иметь в распоряжении какие-то опорные требования, которым должны были бы отвечать все поддерживающие.NET языки.

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

В конечном итоге CLS является своего рода набором правил, которых должны придерживаться создатели компиляторов при желании, чтобы их продукты могли без проблем функционировать в мире.NET. Каждое из этих правил имеет простое название(например, «Правило CLS № 6») и описывает, каким образом его действие касается тех, кто создает компиляторы, и тех, кто (каким-либо образом) будет взаимодействовать с ними. Самым главным в CLS является Правило № 1, гласящее, что: «Правила CLS касаются только тех частей типа, которые делаются доступными за пределами сборки, в которой они определены».

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

Например, возьмём чувствительность к регистру. Язык IL чувствителен к регистру символов. Разработчики, которые пишут на языках, чувствительных к регистру, широко используют гибкость, которую обеспечивает эта зависимость от регистра, при выборе имен переменных. Однако язык Visual Basic 2010 не чувствителен к регистру символов. Спецификация CLS обходит эту проблему указывая, что любой CLS-совместимый код не должен включать никаких пар имён, отличающихся только регистром символов. Таким образом, код Visual Basic 2010 может работать с CLS-совместимым кодом.

 

Этот пример иллюстрирует, что CLS работает двумя способами:

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

 

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

Сборки в.NET Framework

Сборки в.NET Framework

 

Сборки в.NET Framework

 

Какой бы язык .NET не выбирался для программирования, важно понимать, что хотя двоичные.NET-единицы имеют такое же файловое расширение, как и двоичные единицы СОМ-серверов и неуправляемых программ Win32 (*.dll или *.ехе), внутренне они устроены абсолютно по-другому. Например, двоичные.NET-единицы DLL не экспортируют методы для упрощения взаимодействия с исполняющей средой СОМ (поскольку.NET — это не СОМ). Более того, они не описываются с помощью библиотек СОМ-типов и не регистрируются в системном реестре. Пожалуй, самым важным является то, что они содержат не специфические, а наоборот, не зависящие от платформы инструкции на промежуточном языке (Intermediate Language — IL), а также метаданные типов. На следующей схеме показано, как все это выглядит:

 

Рис. 1. 1. Компиляция на различных.NET-языках

 

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

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

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

Тот факт, что сборка содержит метаданные программы, означает, что приложение или другие сборки, которые вызывают код данной, не нуждаются в обращении к реестру или любому другому источнику данных, чтобы узнать, как конкретную сборку следует использовать. Это существенный прорыв по сравнению со старым способом работы СОМ, когда GUID-идентификаторы компонентов и интерфейсов необходимо было извлекать из реестра, а подробности методов и свойств в некоторых случаях читать из библиотеки типов.

Хранение данных в трех различных местах приводило к очевидному риску получить несинхронизированные части, что исключало возможность использования данного компонента другим программным обеспечением. Что касается сборок, то здесь риск подобного рода исключён, потому что все метаданные хранятся вместе с выполняемыми инструкциями программы. Следует отметить, что, несмотря на то, что сборки могут храниться в нескольких файлах, проблема синхронизации не возникает, поскольку в том же файле, где находится точка входа, хранится и информация о содержимом остальных файлов. То есть даже если один из них подменить или испортить, то это немедленно будет обнаружено, и всей сборке будет запрещено загружаться на выполнение.

 

Сборки бывают двух видов: разделяемые и приватные.

 

Приватные сборки

 

Это простейший тип сборок. Обычно они поставляются с определенным программным обеспечением и предназначены для применения только в его составе. Обычный сценарий получения приватной сборки — это когда приложение поставляется в виде исполняемой программы и множества библиотек, код которых может быть использован только этим приложением.

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

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

Поскольку приватная сборка полностью самодостаточна, процесс её развертывания весьма прост. Программист просто помещает соответствующий файл (или файлы) в соответствующую папку системы (никаких записей вносить в реестр не потребуется). Этот процесс известен как установка с нулевым воздействием или установка с помощью хсору (zero impact (хсору) installation).

 

Разделяемые сборки

 

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

• Коллизия имён, когда разделяемая сборка, поставленная другой компанией, реализует типы с теми же именами, что используются в вашей сборке. Поскольку клиентский код теоретически может иметь доступ к двум таким сборкам одновременно, это может представлять серьезную проблему.
• Риск того, что данная сборка будет перезаписана другой версией той же сборки, и новая версия окажется несовместимой с некоторым существующим клиентским кодом.

 

Решение этих проблем включает размещение разделенных сборок в специальном поддереве каталогов файловой системы, известном под названием глобальный кэш сборок (Global Assembly Cache — GAC). В отличие от приватных сборок, это не может быть сделано простым копированием сборки в определенную папку — сборку понадобится специальным образом установить в кэше GAC. Данный процесс может быть реализован с помощью множества утилит.NET и включает в себя выполнение необходимых проверок устанавливаемой сборки, а также создание небольшой иерархии папок в пределах GAC, используемых для обеспечения целостности сборок.

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

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