Обзор среды CLR
.NET предоставляет среду выполнения (среду CLR), которая выполняет код и предлагает службы, облегчающие процесс разработки.
Компиляторы и иные средства позволяют использовать функции среды CLR и дают разработчикам возможность писать код, использующий преимущества этой среды управляемого выполнения. Код, разработанный с использованием языкового компилятора для среды выполнения, называют управляемым. В нем используются преимущества таких средств, как объединение языков программирования, объединенная обработка исключений, усиленная безопасность, поддержка отслеживания версий и развертывания, упрощенная модель взаимодействия компонентов, а также службы отладки и профилирования.
Компиляторы и средства могут создавать выходные данные для общеязыковой среды выполнения (CLR), поскольку система типов, формат метаданных и среда выполнения (виртуальная система выполнения) определяются открытым стандартом — спецификацией общеязыковой инфраструктуры ECMA. Дополнительные сведения см. в разделе Спецификации ECMA для C# и инфраструктуры Common Language Infrastructure (CLI).
Чтобы включить в среде выполнения предоставление служб управляемому коду, языковые компиляторы должны предоставлять метаданные с описанием типов, членов и ссылок в коде. Метаданные хранятся вместе с кодом. Они содержатся в каждом загружаемом переносимом исполняемом (PE) файле среды CLR. Метаданные в среде выполнения используются для поиска и загрузки классов, размещения экземпляров в памяти, разрешения имен при вызове методов, создания машинного кода, обеспечения безопасности и установки границ контекста времени выполнения.
Среда CLR упрощает разработку компонентов и приложений, объекты которых могут работать в разных языках. Объекты, написанные на разных языках, могут взаимодействовать друг с другом, а их поведение может быть тесно интегрировано. Например, разработчик может определить класс, а затем на другом языке создать производный от него класс или вызвать метод из исходного класса. Можно также передать экземпляр класса в метод класса, написанного на другом языке. Такая интеграция языков программирования возможна в силу того, что языковые компиляторы и программы, которые обращаются к среде выполнения, используют систему общих типов, определенную средой выполнения, и следуют правилам среды выполнения при определении новых типов, а также при создании, использовании, сохранении и привязки к типам.
В составе своих метаданных все управляемые компоненты содержат сведения о компонентах и ресурсах, на базе которых они построены. Среда выполнения использует эти сведения, чтобы обеспечить наличие всех необходимых ресурсов для компонента или приложения. Это снижает вероятность сбоев кода из-за каких-либо неудовлетворенных зависимостей. Сведения о регистрации и данные о состоянии больше не сохраняются в реестре, где их трудно задавать и поддерживать. Вместо этого сведения об определяемых разработчиком типах (и их зависимостях) сохраняются вместе с кодом в виде метаданных, что существенно упрощает репликацию и удаление компонентов.
Языковые компиляторы и программы предоставляют функции среды выполнения так, чтобы они были полезны и интуитивно понятны для разработчиков. Это означает, что некоторые средства среды выполнения могут быть заметными в одной среде больше, чем в другой. Характеристики среды выполнения зависят от используемых языковых компиляторов и программ. Например, разработчик Visual Basic при работе со средой CLR может заметить, что язык Visual Basic имеет больше средств объектно-ориентированного программирования, чем раньше. Среда выполнения предоставляет следующие преимущества:
возможность легко использовать компоненты, разработанные на других языках;
расширяемые типы, предоставляемые библиотекой классов;
языковые возможности (например, наследование, интерфейсы и перегрузку) для объектно-ориентированного программирования;
поддержку явной свободной потоковой обработки, позволяющую создавать масштабируемые многопотоковые приложения;
поддержку структурированной обработки исключений;
поддержку настраиваемых атрибутов;
использование делегатов вместо указателей на функции для повышения типобезопасности и уровня защиты. Подробнее о делегатах см. в разделе Система общих типов CTS.
Версии CLR
Общеязыковая исполняющая среда CLR
1. Компиляция исходного кода в Microsoft Intermediate Language (IL)
2. Компиляция IL в специфичный для платформы код с помощью CLR
Основной механизм CLR физически имеет вид библиотеки под названием mscoree.dll (и также называется общим механизмом выполнения исполняемого кода объектов — Common Object Runtime Execution Engine). При добавлении ссылки на сборку для ее использования загрузка библиотеки mscoree.dll осуществляется автоматически и затем, в свою очередь, приводит к загрузке требуемой сборки в память. Механизм исполняющей среды отвечает за выполнение целого ряда задач. Сначала, что наиболее важно, он отвечает за определение места расположения сборки и обнаружение запрашиваемого типа в двоичном файле за счет считывания содержащихся там метаданных. Затем он размещает тип в памяти, преобразует CIL-код в соответствующие платформе инструкции, производит любые необходимые проверки на предмет безопасности и после этого, наконец, непосредственно выполняет сам запрашиваемый программный код.
Использование байт-кода с четко определенным универсальным синтаксисом дает ряд существенных преимуществ:
Независимость от платформы
Повышение производительности
Хотя язык IL выше сравнивался с Java, все же IL на самом деле более гибкий, чем байт-код Java. Код IL всегда компилируется оперативно (Just-In-Time, JIT-компиляция), в то время как байт-код Java часто интерпретируется. Одним из недостатков Java было то, что во время выполнения программ процесс трансляции байт-кода Java в родной машинный код приводил к снижению производительности (за исключением самых последних версий, где Java компилируется оперативно (JIT) на некоторых платформах).
Вместо компиляции всего приложения за один проход (что может привести к задержкам при запуске), JIT-компилятор просто компилирует каждую порцию кода при ее вызове (т.е. оперативно). Если промежуточный код однажды скомпилирован, то результирующий машинный исполняемый код сохраняется до момента завершения работы приложения, поэтому его перекомпиляция при повторных обращениях к нему не требуется. В Microsoft аргументируют, что такой процесс более эффективен, чем компиляция всего приложения при запуске, поскольку высока вероятность того, что крупные фрагменты кода приложения на самом деле не будут выполняться при каждом запуске. При использовании JIT-компилятора такой код никогда не будет скомпилирован.
Это объясняет, почему можно рассчитывать на то, что выполнение управляемого кода IL будет почти настолько же быстрым, как и выполнение родного машинного кода. Однако это не объясняет того, почему Microsoft ожидает повышения производительности. Причина состоит в том, что поскольку финальная стадия компиляции происходит во время выполнения, JIT-компилятор на этот момент уже знает, на каком типе процессора будет запущена программа. А это значит, что он может оптимизировать финальный исполняемый код, используя инструкции конкретного машинного кода, предназначенные для конкретного процессора.
Традиционные компиляторы оптимизируют код, но они могут проводить лишь оптимизацию, не зависящую от конкретного процессора, на котором код будет выполняться. Это происходит потому, что традиционные компиляторы генерируют исполняемый код до того, как он поставляется пользователям. А потому компилятору не известно, на каком типе процессора они будут работать, за исключением самых общих характеристик вроде того, что это будет х86-совместимый процессор либо же процессор Alpha.
COM и COM+
/clr (Компиляция среды CLR)
Позволяет приложениям и компонентам использовать функции среды CLR и выполнять компиляцию C++/CLI.
Синтаксис
/clr [ : /clr ]
Аргументы
options
Один или несколько из следующих аргументов с разделителями-запятыми.
При отсутствии параметров /clr создает метаданные для компонента. Метаданные могут использоваться другими приложениями CLR и позволяют компоненту использовать типы и данные в метаданных других компонентов среды CLR. Дополнительные сведения см. в статье Смешанные (собственные и управляемые) сборки.
netcore
nostdlib
pure
не рекомендуется к использованию. Этот параметр удален в Visual Studio 2017 и более поздних версий. Мы рекомендуем перенести код, который должен быть чистым кодом MSIL, на C#.
safe
не рекомендуется к использованию. Этот параметр удален в Visual Studio 2017 и более поздних версий. Мы рекомендуем перенести код, который должен быть безопасным кодом MSIL, на C#.
noAssembly
Указывает компилятору не вставлять манифест сборки в выходной файл. По умолчанию noAssembly параметр не действует.
initialAppDomain
является устаревшим. Позволяет запускать приложение C++/CLI в среде CLR версии 1. приложение, которое компилируется с помощью, initialAppDomain не должно использоваться приложением, использующим ASP.NET, так как оно не поддерживается в версии 1 среды CLR.
Remarks
Управляемый код — это код, который может проверяться и УПРАВЛЯТЬся средой CLR. Управляемый код может обращаться к управляемым объектам. Дополнительные сведения см. в разделе ограничения.
Сведения о разработке приложений, которые определяют и потребляют управляемые типы в C++, см. в разделе расширения компонентов для платформ среды выполнения.
Приложение, скомпилированное с использованием, /clr может не содержать управляемые данные.
Сведения о включении отладки в управляемом приложении см. в разделе (Add DebuggableAttribute).
При компиляции с помощью служб /c можно указать тип CLR выходного файла с помощью /CLRIMAGETYPE параметра компоновщика.
Все модули, передаваемые в данный вызов компоновщика, должны быть скомпилированы с помощью одного и того же параметра компилятора библиотеки времени выполнения ( /MD или /LD ).
Используйте /ASSEMBLYRESOURCE параметр компоновщика для внедрения ресурса в сборку. /DELAYSIGN /KEYCONTAINER /KEYFILE Параметры компоновщика, и позволяют настроить способ создания сборки.
Если /clr используется, _MANAGED символ определяется как 1. Дополнительные сведения см. в разделе стандартные макросы.
Глобальные переменные в собственном объектном файле инициализируются первыми ( DllMain Если исполняемый файл является библиотекой DLL), а затем инициализируются глобальные переменные в управляемом разделе (перед запуском любого управляемого кода). #pragma init_seg влияет только на порядок инициализации в управляемых и неуправляемых категориях.
Метаданные и неименованные классы
Для просмотра метаданных используйте ildasm.exe.
Установка данного параметра компилятора в среде разработки Visual Studio
Откройте диалоговое окно Страницы свойств проекта. Подробнее см. в статье Настройка компилятора C++ и свойства сборки в Visual Studio.
Задайте для раскрывающегося списка Конфигурация значение все конфигурациии задайте для раскрывающегося списка платформа значение все платформы.
в интегрированной среде разработки Visual Studio /clr параметр компилятора можно настроить отдельно на странице /clr >>>> диалогового окна страницы свойств. Однако мы рекомендуем использовать шаблон CLR для создания проекта. Он задает все свойства, необходимые для успешного создания компонента среды CLR. Другим способом установки этих свойств является использование свойства Поддержка среды CLR на странице Свойства конфигурации Дополнительно диалогового окна страницы свойств. Это свойство задает одновременно все прочие параметры средств, связанных со средой CLR.
Кто может объяснить что такое CLR?
Может кто нибудь объяснить асинхронность?
Здравствуйте, как я не пытался понять, что на самом деле происходит при асинхронном вызове, так и.
Дмитрий3241, я понимаю и никаких претензий не предъявляю 🙂 Я бы просто дал ссылки на английскую википедию, там об этом пишется, хоть и не полностью.
Когда компилируется C# код в *.exe в студии, получается не файл с ассемблерными инструкциями для процессора, а с инструкциями для виртуальной машины, которой является CLR. Код с инструкциями отдается на растерзание JIT-компилятору. Он его компилирует и выполняет уже на понятном процессору языке. Этим достигается кросплатформенность и намного уменьшенные исполнительные файлы.
Утрированно и образно это выглядит так:
— CLR на каждой отдельной платформе/ОС знает как обращаться именно со своей платформой.
— В коде (который в *.exe файле) написано не именно как сделать какую-то операцию, а то, что её нужно сделать, а CLR уже разбирается как это делать. К примеру, в файле не написано как записывать данные в память. Там просто написано «записать ЭТИ данные ТУДА», а CLR сама решает как это сделать, т.к. она знает больше о платформе, чем код из исполняемого файла.
В итоге один и тот же код может работать на разных платформаф, т.к. он не привязан «знанием» только одной платформы.
Рассказал всё очень образно, так что не пинайте сразу 
Кто может объяснить,как построить такое?
В инете ничего дельного не нашел.Смущает то,что здесь дано 3 условия и модули
Знакомство с интеграцией CLR в SQL Server
Если среда CLR размещается в Microsoft SQL Server (что принято называть интеграцией со средой CLR), то появляется возможность разрабатывать в управляемом коде хранимые процедуры, триггеры, определяемые пользователем функции, определяемые пользователем типы и определяемые пользователем статистические функции. Из-за того, что управляемый код перед выполнением производит компиляцию в машинный код, можно достичь значительного увеличения производительности в некоторых сценариях.
В управляемом коде используются управление доступом для кода (CAS), ссылки на код и домены приложений для предотвращения выполнения сборками определенных операций. В SQL Server используется CAS для обеспечения безопасности управляемого кода и предотвращения нарушений безопасности операционной системы или сервера баз данных.
Этот раздел предназначен для предоставления лишь такого количества сведений, с которого можно приступать к программированию в рамках интеграции SQL Server со средой CLR, и не рассчитан на всестороннее изложение. Более подробные сведения см. в статье Общие сведения об интеграции со средойCLR.
Включение интеграции со средой CLR
Интеграцию со средой CLR можно отключить, присвоив параметру clr enabled значение 0. При этом SQL Server прекращает выполнять все процедуры CLR и выгружает все домены приложений.
Более подробные сведения см. в разделе Включение интеграции со средой CLR.
Развертывание сборки среды CLR
После тестирования и проверки методов CLR на тестовом сервере их можно распространить на рабочих серверах с помощью скрипта развертывания. Скриптов развертывания можно создать вручную или с помощью SQL Server Management Studio. более подробные сведения см. в версии SQL Server документации по используемой версии SQL Server.
Документация по SQL Server
Безопасность интеграции со средой CLR
Более подробные сведения см. в разделе безопасность интеграции со средой CLR.
Отладка сборки CLR
В Microsoft SQL Server предоставляется поддержка для отладки кода Transact-SQL и объектов среды CLR в базе данных. Процесс отладки работает с кодом на всех используемых языках: пользователи могут беспрепятственно переходить к коду объектов среды CLR из кода Transact-SQL и наоборот.
Более подробные сведения см. в разделе Отладка объектов базы данных CLR.
