Среда выполнения предоставляет необходимые службы во время выполнения приложении. Традиционно каждой среде программирования соответствует своя среда выполнения. В качестве примера среды выполнения могут служить стандартная библиотека языка С. библиотека базовых классов Microsoft (MFC), среда выполнения языка Visual Basic, а также виртуальная машина Java (Java Virtual Machine). Среда выполнения платформы .NET получила название общеязыковой среды выполнения CLR (Common Language Runtime).
Управляемый код и данные
Общеязыковая среда выполнения CLR (Common Language Runtime) предоставляет в распоряжение .NET-кода ряд служб (включая и библиотеку классов .NET Framework, которая размещается на верхнем слое CLR). Для того чтобы воспользоваться этими службами, .NET-код должен иметь предсказуемое поведение и. к тому же, быть понятным общеязыковой среде выполнения CLR. Например, для того чтобы среда выполнения могла осуществить проверку границ массивов, все массивы в .NET имеют идентичный формат. Требования типовой безопасности могут налагать на .NET-код и другие ограничения.
What is CLR
Ограничения, которые накладываются на .NET-код, определяются общей системой типов (Common Type System, CTS), а также ее реатизацией в промежуточном языке IL, разработанном корпорацией Microsoft (Microsoft Intermediate Language – MSIL, или просто IL). Общей системой типов определены типы и операции, которые могут использоваться кодом, работающим в общеязыковой среде выполнения CLR. Так, именно общей системой типов (Common Type System, CTS) на используемые типы накладывается ограничение единичного наследования реализации. Код на промежуточном языке, разработанном корпорацией Microsoft (Microsoft Intermediate Language, MSIL), компилируется во внутренний (собственный) код платформы.
.NET-приложения содержат в себе метаданные, т.е. описание кода и данных, используемых приложением. Благодаря использованию метаданных возможно автоматическое преобразование данных в последовательную форму общеязыковой средой выполнения CLR при их сохранении.
Код, который может использовать службы, предоставляемые общеязыковой средой выполнения CLR, называется управляемым кодом.
Память для управляемых данных распределяется и освобождается автоматически. Такое автоматическое освобождение занимаемой памяти называется сборкой мусора (garbage collection). Сборка мусора решает все проблемы утечки памяти и им подобные.
Microsoft и Европейская Ассоциация производителей ЭВМ
[European Computer Manufacturers Association (ЕСМА) имеет также другие названия Европейская Ассоциация производителей компьютеров (ЕАПК) и Европейская ассоциация изготовителей ЭВМ Европейская Ассоциация производители ЭВМ разрабатывает стандарты, соблюдаемые большинством фирм, выпускающих ЭВМ и программное обеспечение – Прим. ред.].
Корпорация Microsoft передала с целью стандартизации спецификацию языка С# и основные части библиотеки классов .NET Framework на рассмотрение Европейской Ассоциации производителей компьютеров (European Computer Manufacturers Association – ЕСМА). Техническими требованиями этой независимой международной организации по стандартам определена независимая от платформы инфраструктура универсального языка CLI (Common Language Infrastructure). Общеязыковую среду выполнения CLR можно представить себе как инфраструктуру универсального языка CLI (Common Language Infrastructure), дополненную библиотеками базовых классов BCL (Basic Class Libraries).
Overview of the Common Language Runtime CLR | Information Technology Videos
Библиотека базовых классов BCL (Basic Class Library) поддерживает фундаментальные типы общей системы типов CTS (Common Type System), а именно: ввод/вывод файлов, строки и форматирование. Поскольку общеязыковая среда выполнения CLR зависит от используемой платформы, в ней используются модели управления процессами и памятью базовой операционной системы.
Спецификацией (техническими требованиями) Европейской Ассоциации производителей компьютеров (European Computer Manufacturers Association – ЕСМА) определен универсальный промежуточный язык CIL (Common Intermediate Language). Согласно этим требованиям, разрешено интерпретировать код на промежуточном языке CIL или компилировать его в собственный (внутренний) код.
Верифицируемый код
Управляемый код может быть проверен на предмет типовой безопасности. Код, удовлетворяющий требованиям типовой безопасности, разрушить не так легко. Например, структуры данных или другие приложения, которые находятся в памяти, не могут быть повреждены в результате перезаписи буфера.
Политику безопасности можно применить к коду, удовлетворяющему требованиям типовой безопасности. Например, доступ к некоторым файлам или средствам пользовательского интерфейса может быть разрешен или запрещен. Выполнение кода, происхождение которого неизвестно, можно запретить.
Однако, не все приложения, для работы которых требуется общеязыковая среда выполнения CLR, обязаны удовлетворять требованиям типовой безопасности. В частности, такая ситуация реализуется для приложений, написанных на C++. Управляемый код, написанный на C++, может использовать возможности, предоставляемые общеязыковой средой выполнения CLR, например, сборку мусора. Но так как на C++ может быть создан и неуправляемый код, то нет никаких гарантий относительно того, что приложение, написанное на C++, будет удовлетворять требованиям типовой безопасности.
В управляемом коде, написанном на C++, нельзя выполнять арифметические операции над управляемыми указателями, или приводить тип управляемого указателя к неуправляемому. Поэтому управляемый код, написанный на C++, можно проверить на безопасность. Но может случиться так, что в этом же приложении, написанном на C++, будут выполняться арифметические операции над указателями или приведение типов управляемых указателей к неуправляемым. А это, по своей сути, ненадежно.
Источник: samoychiteli.ru
Русские Блоги
Одна из основ CLR — Понимание CLR [«CLR via C #» чтение заметок]
«CLR via C #» Чтение Заметок
Common Language Runtime (CLR) — это имя, которое Microsoft выбрала для своей виртуальной машины .Net. Это реализация Microsoft Common Language Architecture (CLI) от Microsoft, которая определяет среду, в которой выполняется код. CLR выполняет тип байт-кода, называемый «Common Intermediate Language», который является версией реализации Microsoft Common Intermediate Language. CLR работает в операционной системе Microsoft Windows. См. Common Language Architecture для списка версий реализации спецификации. Некоторые из этих версий работают в операционных системах, отличных от Windows. (Википедия CLR)
- CLR — это виртуальная машина, похожая на JVM, которая обеспечивает работающую среду для продуктов Microsoft .Net.
- На самом деле в CLR работает не язык программирования, который мы обычно используем (например, C #, VB и т. Д.), А «промежуточный язык» в форме байт-кода. Это означает, что, пока код может быть скомпилирован в этот конкретный «промежуточный язык» (MSIL), продукты на любом языке могут работать на CLR.
- CLR обычно запускается в системах Windows, но есть некоторые версии, отличные от Windows. Это означает, что .Net также легко «кроссплатформенный». (Что касается того, почему у всех сложилось впечатление, что кроссплатформенность .Net не так хороша, как Java, и это больше обусловлено бизнес-стратегией Microsoft.)
Отношения между CLR и .Net Framework
.NET Framework (.NET Framework) разработана Microsoft, платформой для разработки программного обеспечения, предназначенной для быстрой разработки программного обеспечения (гибкая разработка программного обеспечения), быстрой разработки приложений (быстрая разработка приложений), независимости платформы и прозрачности сети. .NET Framework — это программная платформа, использующая для запуска системную виртуальную машину, основанная на Common Language Runtime и поддерживающая разработку нескольких языков (C #, VB.NET, C ++, Python и т. Д.). (Википедия. Net Framework)
Можно видеть, что .Net Framework — это платформа разработки, которая поддерживает несколько языков разработки, и эта многоязычная поддержка должна основываться на CLR. CLR — это рабочая среда для продуктов .Net. Среда исполнения общего языка и библиотека классов .Net Framework (FCL) являются двумя основными компонентами .Net Framework.
CLR>=CLR+CLI+FCL。
Какие языки в настоящее время поддерживают CLR
Microsoft разработала CLR-компиляторы для нескольких языков, включая: C ++ / CLI, C #, Visual Basic, F #, Iron Python, Iron Ruby и IL. Кроме того, некоторые другие компании и университеты разработали основанные на CLR компиляторы на некоторых языках, таких как Ada, APL, Caml, COBOL, Eiffel, Forth, Fortran, Haskell, Lexicon, LISP, LOGO, Lua, Меркурий, ML, Мондриан, Оберон, Паскаль, Perl, PHP, Пролог, RPG, Схема, Смальтак, Tcl / Tk.
CLR предоставляет унифицированную операционную платформу для разных языков программирования и в значительной степени защищает разработчиков верхнего уровня от различий в функциях между языками. Для CLR компилятор на разных языках эквивалентен контролеру для этого языка. Задача состоит в том, чтобы проверить правильность синтаксиса исходного кода, а затем скомпилировать исходный код на промежуточный язык, требуемый CLR. (IL). Следовательно, язык программирования прозрачен для CLR, что означает, что CLR знает только существование IL и не знает, из какого языка был скомпилирован IL.
Эта функция «общего языка» CLR делает возможным «многоязычное смешанное программирование», позволяя разработчикам APL использовать свои знакомые языки и синтаксис для разработки проектов на основе .Net. Конечно, что более важно, эта функция позволяет разрабатывать разные модули одного и того же проекта на разных языках, например, разработку пользовательского интерфейса в проекте с Visual Basic, разработку финансовых модулей с APL и модулей, связанных с математическими вычислениями. Используя F # и полностью используя возможности этих языков, вы получите неожиданные результаты.
Что такое CLS
Как упоминалось выше, CLR объединяет все эти языки, так что один язык программирования может использовать объекты, созданные другим языком программирования. Интеграция языков является большой целью. Однако необходимо учитывать тот факт, что между различными языками программирования существуют большие различия, например, некоторые языки не поддерживают перегрузку операторов, некоторые языки не поддерживают необязательные параметры и т. Д. Чтобы обеспечить безопасный доступ к объектам, созданным на языке CLR-ориентированного программирования, с помощью других языков, ориентированных на CLR, лучше всего использовать при программировании на этом языке только те функции, которые поддерживаются всеми языками CLR-ориентированного программирования. , С этой целью Microsoft специально определила «Спецификацию общего языка» или CLS. CLS определяет минимальный набор функций. Любой тип, сгенерированный CLR-ориентированным компилятором, должен поддерживать этот минимальный набор функций, если он совместим с другими «CLS-совместимыми, CLR-ориентированными» компонентами.
CLR / CTS поддерживает гораздо больше, чем подмножество, определенное CLS. Если вас не волнует взаимодействие между языками, вы можете разработать очень многофункциональный тип, который ограничен только набором функций выбранного вами языка. В частности, при разработке типов и методов, если вы хотите, чтобы они были «видимы» для внешнего мира и были доступны из любого CLS-совместимого языка программирования, вы должны следовать правилам, определенным CLS. Обратите внимание, что правила CLS не применяются, если к коду обращаются только из сборки, которая определяет код.
До сих пор, за исключением языка ассемблера IL, который поддерживает все функциональные возможности CLR, большинство других CLR-ориентированных языков предоставили только часть функциональности CLR. То есть функции этих языков являются подмножеством функциональных характеристик CLR, но для обеспечения взаимодействия с другими языками их функции являются надмножеством CLS (но не обязательно тем же надмножеством).
Для получения дополнительной информации о CLS, пожалуйста,Нажмите здесь。
Если вы хотите написать CLS-совместимый код, вы должны убедиться, что несколько частей кода соответствуют CLS.
- Определение общественного класса
- Определения открытых членов в открытых классах и определения членов, к которым могут обращаться производные классы (семейный доступ).
- Параметры и возвращаемые типы открытых методов в открытых классах, а также параметры и возвращаемые типы методов, к которым могут обращаться производные классы.
Совет: Функции, используемые в определении вашего частного класса, в определении частных методов для открытых классов и локальных переменных, не должны следовать правилам CLS. Вы также можете использовать любую языковую функцию в коде, который реализует ваш класс, и оставить его как CLS-совместимый компонент.
Примечание: зубчатые массивы соответствуют CLS. В .NET Framework версии 1.0 компилятор C # неправильно сообщил о его несоответствии.
Вы можете использовать CLSCompliantAttribute, чтобы пометить сборки, модули, типы и элементы как CLS-совместимые или не-CLS-совместимые. Сборки, которые не помечены как CLS-совместимые, будут считаться несовместимыми с CLS. Если к типу не применяется атрибут CLS, считается, что тип имеет такое же соответствие CLS, что и сборка, в которой определен тип. Точно так же, если к члену не применяется атрибут CLS, считается, что член имеет такое же соответствие CLS, что и тип, который определяет член. Программный элемент не может быть помечен как CLS-совместимый, если он содержит элементы, которые не помечены как CLS-совместимые.
Следующий код иллюстрирует использование CLSCompliantAttribute:
using System; // Скажите компилятору проверить, соответствует ли код CLS [assembly: CLSCompliant(true)] namespace CLS_CS public class CsClass // Предупреждение: тип возвращаемого значения «CLS_CS.CsClass.Abc ()» не соответствует CLS // UInt32 не соответствует CLS. public UInt32 Abc() < return 0; > // Предупреждение: только идентификатор «CLS_CS.CsClass.abc ()» с другим регистром // abc и Abc — это два имени метода, которые отличаются только регистром. public void abc() //Нет предупреждения: частные методы не будут вызывать CLSC-совместимые правила private UInt32 ABC() < return 0; > > >
При компиляции этого кода из-за использования функции [assembly: CLSCompliant (true)] компилятор проверит, соответствует ли код CLS, и выдаст предупреждение для деталей, которые не соответствуют CLS.
Фактически, если выполняются следующие два условия, даже если некоторые части сборки, модуля или типа не соответствуют CLS, эти сборки, модули или типы соответствуют CLS:
- Если элемент помечен как CLS-совместимый, то CLSCompliantAttribute (и его параметр должен быть установлен в false) должен использоваться для маркировки несовместимой с CLS части.
- Каждый CLS-совместимый участник должен быть снабжен соответствующим CLS-совместимым сменным элементом.
Для первого условия, пока [CLSCompliant (false)] используется в соответствующем месте в приведенном выше коде, компилятор больше не будет генерировать эти предупреждения, и будет сгенерирована CLS-совместимая сборка.
using System; // Скажите компилятору проверить, соответствует ли код CLS [assembly: CLSCompliant(true)] namespace CLS_CS public class CsClass // Нет предупреждения // UInt32 не соответствует CLS. [ CLSCompliant(false)] public UInt32 Abc() < return 0; > // Нет предупреждения // abc и Abc — это два имени метода, которые отличаются только регистром. [CLSCompliant(false)] public void abc() //Нет предупреждения: частные методы не будут вызывать CLSC-совместимые правила private UInt32 ABC() < return 0; > > >
Однако, таким образом, модули на других языках не могут легко получить доступ к этим членам. При необходимости требуется второе условие, то есть соответствующий CLS-совместимый сменный элемент предоставляется для не CLS-совместимого элемента.
Чтобы облегчить разработку, некоторые компиляторы проделали для нас аналогичную работу, то есть на этапе компиляции некоторые функции, которые не соответствуют CLS, были скомпилированы в CLS-совместимые функции. Здесь мы берем перегрузку операторов в качестве примера.Как упоминалось ранее, некоторые CLR-ориентированные языки не поддерживают перегрузку операторов, поэтому перегрузка операторов не является частью CLS. Так как же компилятор справляется с перегрузкой операторов? Следующий код просто иллюстрирует перегрузку операторов «»:
using System; // Скажите компилятору проверить, соответствует ли код CLS [assembly: CLSCompliant(true)] namespace CLS_CS public class Operatorcs // Перегруженный оператор public static Boolean operator >(Operatorcs t1, Operatorcs t2) return true; > // > И public static Boolean operator (Operatorcs t1, Operatorcs t2) return true; > > >
Скомпилируйте этот код в сборку, а затем используйте декомпилятор IL для просмотра сгенерированного кода IL. Я использую ILDasm.exe здесь, конечно, вы также можете использовать некоторые другие инструменты, такие как .Net Reflector, ILSpy и т. Д.
Видно, что скомпилированный код IL не имеет никакой информации об операторах «>» и «GreaterThan «и» op»LessThan» статический метод, а возвращаемое значение и сигнатура этих двух методов согласуются с методом перегрузки операторов в исходном коде. Следовательно, можно сделать вывод, что компилятор «переводит» перегрузку оператора в соответствующий статический член.
Это правда. Хотя перегрузка операторов не является частью CLS, все CLR-ориентированные, CLS-совместимые языки поддерживают типы, элементы, атрибуты и поля. Компилятор использует это, чтобы заменить CLS-совместимую перегрузку операторов на CLS-совместимые методы-члены, умело избегая проверки правил CLS, поэтому этот код использует [assembly: CLSCompliant (true)], но не Сообщите причину предупреждения «Не соответствует CLS».
Что такое CTS
Имейте в виду, что реализация всех функций CLR основана на типах. Один тип обеспечивает функциональность для одного приложения или другого типа для использования. По типу код, написанный на одном языке программирования, может взаимодействовать с кодом, написанным на другом языке. Поскольку типы являются основой CLR, Microsoft определила формальную спецификацию для определения, использования и управления типами — Common Type System или CTS.
CTS предоставляет спецификации для определений типов и поведенческих характеристик, включая, помимо прочего, следующее:
- Члены класса (Поле, Метод, Свойство, Событие)
- Уровни видимости доступа (частный, семейный, семейный и сборочный, сборочный, семейный или сборочный, общественный)
- Тип наследования
- интерфейс
- Виртуальный метод
- Жизненный цикл объекта
В то же время правило, согласно которому все ссылочные типы должны наследоваться от System.Object, также определено в CTS.
Вообще говоря, CLS в основном обеспечивает следующие функции:
Займи здесьJeffrey RichterЦитата из:
At first, I thought that the .NET Framework was an abstraction layer over the Win32 API and COM. As I invested more and more of my time into it, however, I realized that it was much bigger. In a way, it is its own operating system. It has its own memory manager, its own security system, its own file loader, its own error handling mechanism, its own application isolation boundaries (AppDomains), its own threading models, and more.
Хотя в исходном тексте Джеффри Рихтер сказал .Net Framework, ясно, что эти функции обеспечиваются основным компонентом CLR .Net Framework.
Именно CLR делает .Net Framework не абстрагирующим уровнем Win32 API и COM, но С его собственной «операционной системой» (Джеффри Рихтер в некоторой степени означает, что виртуальные машины также можно считать небольшой операционной системой). Подводя итог, CLR в основном обеспечивает следующие функции:
- Поддержка библиотеки базовых классов
- Управление памятью
- Управление потоками
- Сборка мусора
- Безопасность (Security)
- Тип проверки
- Менеджер исключений
- Даже компилировать (JIT)
Эта серия посвящена CLR на основе вышеуказанных функций.
Источник: russianblogs.com
IT Notes
Наиболее важный компонент .NET Framework — это общеязыковая среда выполнения Common Language Runtime (CLR). CLR управляет кодом и исполняет код, написанный на языках .NET, и является фундаментом всей архитектуры .NET, подобно виртуальной машине Java. CLR активизирует объекты, выполняет для них проверку безопасности, располагает в памяти, исполняет их и выполняет сборку мусора.
Сейчас мы рассмотрим среду CLR, исполняемые файлы, метаданные, сборки, манифесты, CTS и CLS.
CLR — это инфраструктура, лежащая в основе .NET. В отличие от таких библиотек программного обеспечения, как MFC или ATL, CLR построена с чистого листа. CLR управляет исполнением кода в .NET Framework.
(Сборка (asseтbly) — это основная единица для развертывания и контроля версий, состоящая из манифеста, набора из одного или более модулей и необязательного набора ресурсов.)
 |
На рис. 2.1 показаны две части среды .NET: нижняя — это CLR, а верхняя — исполняемые файлы CLR или переносимые исполняемые файлы (Portable Executable, РЕ), являющиеся сборками .NET или единицами развертывания. CLR — это механизм времени выполнения, загружающий требуемые классы, выполняющий оперативную (just-in-time) компиляцию необходимых методов, проверку безопасности и много других функций времени выполнения. Исполняемые файлы CLR, показанные на рис. 2.1, являются ЕХЕ- или DLL-файлами, состоящими в основном из метаданных и кода.
Рис. 2.1. Среда CLR
Переносимый исполняемый файл .NET
Исполняемый файл Windows, ЕХЕ или DLL, должен соответствовать формату, который называется форматом РЕ и является производным от формата Мiсrоsоft Common Object File Format (COFF). Для обоих этих форматов существуют и свободно доступны полные спецификации. ОС Windows знает, как загружать и исполнять DLL- и ЕХЕ-файлы, т. к. понимает формат РЕ-файла. Поэтому любой компилятор должен генерировать исполняемый файл Windows в соответствии со спецификацией PE/COFF.
Стандартные РЕ-файлы Windows делятся на две основных секции. Первая включает в себя заголовки PE/COFF со ссылками на содержимое внутри РЕ-файла. Кроме секции заголовков в РЕ-файле имеется несколько секций двоичных образов, включающих секции .data, .rdata, .rsrc и .text.
Это стандартные секции типичного исполняемого файла Windows, однако компилятор Мiсrоsоft С и С++ позволяет добавлять в РЕ-файл собственные секции с помощью директивы компилятора pragma. Например, можно создать собственные секции, содержащие зашифрованные данные, которые сможете читать только вы сами. Пользуясь этой возможностью, Мiсrоsоft добавила несколько новых секций в обычный РЕ-файл специально для поддержки функциональности CLR. Среда CLR понимает и управляет новыми секциями. Например, она читает эти секции и определяет, каким образом загружать классы и выполнять ваш код.
Рис. 2.2. Формат РЕ-файла .NET
Метаданные (metadata) — это данные о ресурсах, или «данные о данных», предназначенные для чтения машиной. Это могут быть подробные сведения о содержимом, формате, размере или других характеристиках источника данных. В .NET метаданные включают определения типов, сведения о версии, ссылки на внешние сборки и другую стандартизованную информацию.
В Microsoft .NET метаданные служат для описания всех типов, используемых и предоставляемых данной сборкой .NET. В этом смысле метаданные описывают сборку в деталях, включая ее идентификатор (комбинация имени сборки, версии, культуры и открытого ключа), типы, на которые она ссылается, экспортируемые типы и требования безопасности для исполнения. Метаданные включают описания сборки и модулей, классов, интерфейсов, методов, свойств, полей, событий, глобальных методов и т. д.
Метаданные предоставляют достаточно информации для любой среды выполнения, утилиты или программы, чтобы выяснить буквально все, что требуется для интеграции компонентов.
Метаданные гарантируют возможность межъязыкового взаимодействия, основного элемента .NET, т. к. все языки должны использовать одни и те же типы, чтобы сгенерировать корректный РЕ-файл для .NET, которая не сможет во время выполнения поддерживать функции управления памятью, безопасности, распределения памяти, проверки типов, отладки и т. д. без метаданных. Вот почему метаданные — крайне важная часть .NET, столь важная, что мы спокойно можем утверждать, что без метаданных не было бы .NET.
Сборки и манифесты
Как мы только что видели, типы должны предоставлять свои метаданные, чтобы утилиты и программы могли обращаться к ним и пользоваться предоставляемыми ими сервисами. Но одних метаданных недостаточно. Чтобы упростить программный plug-and-play, а также настройку и установку компонента или программного обеспечения, нам также потребуются метаданные о компонентах, которые содержат эти типы. Сейчас мы поговорим о сборках .NET (единицах развертывания) и манифестах (метаданных, описывающих сборки).
Сборки и компоненты
В эпоху СОМ в документации Мiсrоsоft термин компонент (сотропent) непоследовательно применялся для обозначения как класса СОМ, так и СОМ-модуля (DLL или ЕХЕ), заставляя читателей или разработчиков каждый раз рассматривать контекст, окружающий термин. В .NET Microsoft разрешила эту путаницу, введя новую концепцию сборки (asseтbly), являющейся компонентом программного обеспечения, поддерживающим plug-and-play, во многом аналогично аппаратному компоненту. Теоретически .NЕТ-сборка примерно эквивалентна СОМ-модулю. Практически сборка может содержать несколько типов и физических файлов (в том числе файлов растровой графики, РЕ-файлов .NET и т. д.), необходимых для ее успешного запуска, или ссылаться на них. Кроме хранения IL-кода сборка является базовой единицей контроля версии, развертывания, управления безопасностью, одновременного исполнения версий, совместного и повторного использования кода, что мы обсудим далее.
(Для справки: сборка — это логический DLL- или ЕХЕ-файл, а манифест — описание (метаданные) сборки (в том числе ее версия, используемые в ней другие сборки и т. д.).)
Уникальная идентификация
Все сборки, совместно используемые многими приложениями (и называемые совместно используемыми или разделяемыми сборками (shared asseblies)), должны содержать пару из открытого и закрытого ключа. Создатель сборки может подписать сборку своим закрытым ключом, а любой другой — проверить эту цифровую подпись с помощью открытого ключа создателя сборки.
Для цифровой подписи сборки необходимо при создании последней использовать открытый и закрытый ключи. На этапе компиляции компилятор сгенерирует хеш-код файлов сборки, подпишет его с помощью закрытого ключа и сохранит получившуюся цифровую подпись в зарезервированном разделе РЕ-файла. Открытый ключ будет также сохранен в сборке.
Чтобы проверить цифровую подпись сборки, CLR нужен открытый ключ сборки для расшифровки ее цифровой подписи и получения исходного, рассчитанного ранее хеш-кода. Кроме того, CLR опирается на информацию из манифеста сборки для динамической генерации хеш-кода. Сгенерированное значение сравнивается с исходным значением хеш-кода. Эти значения должны совпадать, в противном случае предполагается, что сборка поддельная.
Теперь, когда мы знаем как подписать и проверить подлинность сборки в среде .NET, поговорим о том, как CLR гарантирует, что данное приложение загружает именно ту сборку, с которой оно компилировалось. Когда вы или кто-то еще компилирует приложение, для работы которого требуется совместно используемая сборка, в манифест сборки приложения будет включен 8-байтовый хеш-код, полученный с помощью открытого ключа совместно используемой сборки. При запуске приложение динамически вычисляет 8-байтовый хеш-код по открытому ключу сборки и сравнивает его со значением, хранящимся в манифесте сборки приложения. Если эти значения совпадают, CLR предполагает, что была загружена корректная версия сборки.
Контроль версий
В .NET существует четыре типа сборок:
Статические сборки
В .NET существуют РЕ-файлы, создаваемые при компиляции. Статические сборки могут быть созданы с помощью вашего любимого компилятора: свс, cl или иЬс.
Динамические сборки
Это сборки в памяти, имеющие формат РЕ, динамически создаваемые во время выполнения с помощью классов пространства имен System.Reflection.Emit.
Закрытые сборки
Это статические сборки, используемые конкретным приложением.
Совместно используемые или разделяемые сборки
Это статические сборки, которые должны иметь уникальное разделяемое имя и доступны любому приложению
В .NET сборка является минимальной единицей, которой может быть присвоен номер версии, имеющий следующий формат:
Развертывание
Поскольку манифест сборки клиентского приложения (что мы кратко обсудим далее) содержит информацию о внешних ссылках — в том числе местоположение внешней сборки и версию сборки, используемую приложением, — больше не требуется хранить в реестре указания по активизации компонентов и маршалингу, как в СОМ. Основываясь на информации о версии и безопасности, записанной в манифесте приложения, CLR загрузит корректную совместно используемую сборку. I CLR выполняет «ленивую» (отложенную) загрузку внешних сборок и извлечет их код по запросу, когда приложению потребуются типы из них. По этой причине можно уменьшать размер загружаемых приложений с помощью многочисленных небольших внешних сборок. Когда потребуется определенная внешняя сборка, среда времени выполнения загрузит ее автоматически, не требуя регистрации или перезагрузки компьютера.
Безопасность
Концепция идентификации пользователя является общей для всех платформ разработки и операционных систем, однако концепция идентичности кода (code identity), в соответствии с которой может идентифицироваться даже фрагмент кода, нова для индустрии коммерческого программного обеспечения. В среде .NET сама сборка представляет собой единицу идентификации кода, включающую такую информацию, как имя совместно используемой сборки, номер версии, информацию о культуре (для локализации приложений) и открытый ключ. Опираясь на эту концепцию, CLR может проверить, имеет ли сборка полномочия на доступ к системным ресурсам и на вызовы других сборок.
Для того чтобы соответствовать концепции идентичности кода, CLR поддерживает концепцию управления доступом к коду (code access). Другими словами, среда времени выполнения определяет возможность доступа к определенной сборке на основе набора разрешений. CLR проверяет эти разрешения и определяет, удовлетворять ли запросы на исполнение на уровне сборки. При создании сборки можно указать набор разрешений, которые клиентское приложение должно иметь для доступа к вашей сборке. Во время выполнения, если клиентское приложение имеет права на доступ к коду вашей сборки, оно может выполнять вызовы ее объектов, а в противном случае оно не сможет их использовать.
Одновременное исполнение версий