среда 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?
Может кто нибудь объяснить асинхронность?
Здравствуйте, как я не пытался понять, что на самом деле происходит при асинхронном вызове, так и.
Дмитрий3241, я понимаю и никаких претензий не предъявляю 🙂 Я бы просто дал ссылки на английскую википедию, там об этом пишется, хоть и не полностью.
Когда компилируется C# код в *.exe в студии, получается не файл с ассемблерными инструкциями для процессора, а с инструкциями для виртуальной машины, которой является CLR. Код с инструкциями отдается на растерзание JIT-компилятору. Он его компилирует и выполняет уже на понятном процессору языке. Этим достигается кросплатформенность и намного уменьшенные исполнительные файлы.
Утрированно и образно это выглядит так:
— CLR на каждой отдельной платформе/ОС знает как обращаться именно со своей платформой.
— В коде (который в *.exe файле) написано не именно как сделать какую-то операцию, а то, что её нужно сделать, а CLR уже разбирается как это делать. К примеру, в файле не написано как записывать данные в память. Там просто написано «записать ЭТИ данные ТУДА», а CLR сама решает как это сделать, т.к. она знает больше о платформе, чем код из исполняемого файла.
В итоге один и тот же код может работать на разных платформаф, т.к. он не привязан «знанием» только одной платформы.
Рассказал всё очень образно, так что не пинайте сразу 
Кто может объяснить,как построить такое?
В инете ничего дельного не нашел.Смущает то,что здесь дано 3 условия и модули
Практическое руководство. Создание консольного приложения CLR (C++/CLI)
шаблон консольного приложения CLR в диалоговом окне New Project можно использовать для создания проекта консольного приложения, в котором уже есть важный набор ссылок и файлов проекта.
Как правило, консольное приложение компилируется в автономный исполняемый файл, но не имеет графического интерфейса пользователя. Пользователи запускают консольное приложение из командной строки. Они могут использовать командную строку для выполнения инструкций в работающем приложении. Приложение предоставляет выходные данные в виде текста в командном окне. Немедленная обратная связь консольного приложения делает его отличным средством для обучения программированию. Не нужно беспокоиться о том, как реализовать графический пользовательский интерфейс.
При создании проекта с помощью шаблона консольного приложения CLR автоматически добавляются следующие ссылки и файлы:
System, System. Data, System.Xml: эти ссылки содержат фундаментальные классы, определяющие часто используемые типы, события, интерфейсы, атрибуты и исключения.
ConsoleApplicationName.cpp : Основной исходный файл и точка входа в приложение. Этот файл содержит базовое имя, указанное для проекта. Он определяет DLL-файл проекта и пространство имен проекта. В этом файле содержится разработанный вами код.
AssemblyInfo.cpp : Содержит атрибуты и параметры, которые можно использовать для изменения метаданных сборки проекта. Дополнительные сведения см. в разделе содержимое сборки.
app.rc : Файл описания ресурсов программы.
app.ico — Файл значка программы.
ReadMe.txt : Описывает файлы в проекте.
При создании проекта с помощью шаблона консольного приложения CLR автоматически добавляются следующие ссылки и файлы:
System, System. Data, System.Xml: эти ссылки содержат фундаментальные классы, определяющие часто используемые типы, события, интерфейсы, атрибуты и исключения.
ConsoleApplicationName.cpp : Основной исходный файл и точка входа в приложение. Этот файл содержит базовое имя, указанное для проекта. Он определяет DLL-файл проекта и пространство имен проекта. В этом файле содержится разработанный вами код.
AssemblyInfo.cpp : Содержит атрибуты и параметры, которые можно использовать для изменения метаданных сборки проекта. Дополнительные сведения см. в разделе содержимое сборки.
app.rc : Файл описания ресурсов программы.
app.ico — Файл значка программы.
Создание проекта консольного приложения CLR
в строке меню выберите файл создать Project.
В поле Имя введите уникальное имя для приложения.
Можно указать другие параметры проекта и решения, но они не являются обязательными.
в строке меню выберите файл создать Project.
В поле Имя введите уникальное имя для приложения.
Можно указать другие параметры проекта и решения, но они не являются обязательными.
в строке меню выберите файл создать Project.
В поле Имя введите уникальное имя для приложения.
Можно указать другие параметры проекта и решения, но они не являются обязательными.
Накалу страстей такой беседы позавидовали бы религиозные фанатики. Единственное, что спасает противников от крестовых походов друг на друга, вооружившись вилами и LangSpec’ами — то, что они разделены интернетом.
Так жить нельзя, господа. Мне захотелось исправить эту ситуацию, и выступить с одной из сторон. Этим постом я попробую нанести сообществу непоправимую пользу и разобраться с мифами, на обсуждение которых, а не на взаимное членовредительство, к сожалению, и уходят силы спорщиков. А так как я в своё время перелез с C++ на C# и всё вокруг него, то я буду развенчивать негативные мифы, прибавлять позитива и всячески приукрашивать действительность — а как без этого. И — заметьте — это обойдется совершенно бесплатно для M$. Ну а сделать я это хочу в формате Q&A.
#. C# и CLR — это такая VM, т.е. интерпретатор, а, значит, очень медленно и печально. Мне нужно, чтобы было быстро, очень быстро!
Я не буду рассказывать тут, чем компиляция отличается от интерпретации. Просто хочу заметить вот что: джентльмены, недавний опрос на Хабрахабре показал — большинство разработчиков так или иначе используют “управляемые” языки, которые компилируются не в нативный код, а в байт-коды, исполняемые интерпретаторами — непосредственными или компилирующего типа. Всякие TraceMonkey, LuaJIT, YARV как раз примеры для последней классификации. Это означает, что переход на другую платформу сходной архитектуры заведомо не сделает приложение медленнее. В этом смысле беспокоиться не о чем.
Однако, CLR — это sort of virtual machine, но это не интерпретатор. Еще раз повторюсь: MS.NET это НЕ ИНТЕПРЕТАТОР БАЙТКОДА. Специальный компилятор JIT постепенно преобразует байткод программы в нативный код, примерно такой же, который выдаёт компилятор C++. Текущая реализация CLR — MS.NET и Mono гарантируют, что ЛЮБОЙ код, который будет исполняться, преобразуется в нативный код. При этом для десктопов утверждение еще сильнее: любой код будет откомпилирован только один раз. Причём то, что он компилируется “на лету”, теоретически позволяет более оптимально использовать особенности конкретного процессора, а значит, сильнее соптимизировать код.
Более того, сравнение абсолютных цифр на бенчмарках показывает, что CLR оказывается на порядки эффективнее, чем популярные скриптовые языки типа JavaScript и Ruby, тоже использующие технологию JIT.
#. Языки со сборкой мусора отстают от языков типа C++ по скорости.
Верно, тут вы весьма близки к истине. Но, как и любой холиварщик, немного не договариваете. Правильно фраза будет звучать так: “корректно написанное и целиком вручную оптимизированное нативное приложение без ошибок, использующее специальные методики управления памятью, будет быстрее, чем приложение с автоматической сборкой мусора”.
Но для более-менее серьезного ПО создать такое приложение означает огромное количество затраченных усилий. Значительно превышающее то, которое потребуется для управляемого языка.
Именно поэтому появились языки высокого уровня — в длительной перспективе в среднем код, выдаваемый компилятором, будет содержать меньше ошибок и работать быстрее, чем написанный вручную.
И — да — тупые цифры не лгут: выделение памяти в языках со сборкой мусора выполняется БЫСТРЕЕ, и _не_ фрагментирует кучу, в отличие от с++. Обработка исключений в управляемых языках тоже выполняется быстрее.
А тут еще в дело вступает фактор времени, и стоимости разработки, включая количество ошибок. Потому что ошибка повреждения или утекшей памяти… хм… когда же я её видел в CLR последний раз? Лет 10 назад, не меньше.
#. Программы на CLR жрут очень много памяти. Прям вааще всё жрут, ничего не оставляют…
Хм. Сравнимое нагруженное Ruby-on-Rails-приложение на сервере кушает 100-150МБ RAM, примерно столько же, сколько и ASP.NET CLR сайт. Тут нет большой разницы.
Конечно, в небольших скриптовых задачах тот же Ruby оказывается гораздо эффективнее. Но вопрос не о скриптовых задачах — на проектах из реальной жизни, которые приносят деньги, аппетиты CLR выглядят соразмерными другим технологиям, и я не могу согласиться с определением “жрут очень много”.
#. Ну ладно, ладно, GC это хорошо. Но сборщик мусора — очень капризное животное, там есть огромное количество настроек. Их же никто не может корректно выставить — ручное вмешательство только вредит. GC в моём ZZZ работает и так! Сам!
Между прочим, CLR обладает одним из лучших сборщиков мусора на сегодняшний день. Первый его вариант был написан на LISPe, чтобы явственнее выразить семантику отношений между объектами в памяти и выполнить автоматический анализ корректности алгоритма, а затем переписан на С++. С тех пор прошло много времени, GC был обкатан миллионами разработчиков и не меньшим количеством проектов. Не течёт, что ни делай!
В качестве настроек выступает один ключ в файле конфигурации gcServer=”true/false”. Включает параллельную сборку мусора, а так же другие оптимизации. По умолчанию стоит в false, чтобы не мешать интерактивному режиму UI (работа gc незаметна для UI) на однопроцессорных машинах. В CLR 4.0 появились новые настройки, но суть та же — отлично работает “из коробки”, убирайте свои пассатижи подальше.
#. А в моём любимом языке ZZZ есть FFI, и поэтому я могу писать к нему расширения на С, если мне нужна скорость. Ни разу, правда, не писал, ну и что! Ведь могу же! А что в CLR/C#, надо всё переписывать на управляемый язык?
Очень рад за ZZZ. Вы удивитесь, но в CLR тоже присутствует возможность вызывать функции из нативных dll, написанных на старом добром С. И, конечно, передавать туда данные и получать обратно. Причем, в отличие от большинства FFI, вам не нужно проектировать dll под FFI — использовать соглашения по вызову и специальные типы данных. CLR всеяден, его можно гибко настроить на поедание почти любой библиотеки. Отдельным образом включена и автоматизирована поддержка COM, для более удобного доступа к возможностям Windows.
Это называется Interop/Platform Invoke
#. Писать для CLR можно только из Visual Studio. И только под Windows. И то, и то опять стоит денег.
Неправда. Есть SharpDevelop, который достаточно хорош для бесплатной среды; есть MonoDevelop, который тоже хорош, и работает как по Win, так и в *nix. Есть плагины к Eclipse; кстати, при помощи IKVM.NET для запуска Eclipse не нужна Java, хватает одного CLR.
Облегченная версия Visual Studio Express позволяет создавать полноценные приложения в Win. Бесплатного MS SQL Express хватит надолго для большинства проектов.
#. Место CLR — на сервере. А Mono — страшная неюзабельная ненадежная гадость, не выросшая из пеленок MiguelDeIcaza’s Labs ©.
Точно. На сервере приложений и на веб-сервере — в CLR есть свои Rails (ASP.NET MVC), есть свой Hibernate и десятки других ORM. Подойдёт для всего. Ну это разве страшно — мы все постепенно переползаем в веб.
Кстати, а вы слышали, что приложения Mono компилируется и для iPhone и iPad (#MonoTouch)? Да и тот же Unity3D это умеет.
#. Использование CLR заставляет меня переходить на C#, я не хочу его учить!
И совершенно не нужно. Да, в C# наиболее полно доступны все возможности CLR, но никто не заставляет пользоваться именно им. CLR — это не только C#, это отличная платформа и BCL, предоставляющая качественную объектную модель и инструменты. Существует огромное количество языков — новых, таких, как Boo, Nemerle, F#, или ранее известных: Delphi, Ada, Lisp, VB, php, в качестве back-end использующих CLR.
С этой точки зрения CLR похожа на LLVM — предоставляет сервисы нижнего уровня, такие, как IL (байт-код) и JIT, сборка мусора, объектная модель, общая система типов, стандартная библиотека, система безопасности и т.д.
#. С# это быдлоязык для ыnterprise, он застрял в прошлом веке, а в моём языке ZZZ каждые полгода новые фишечки!
Да, C# сейчас плотно обосновался в low-cost секторе enterprise — всё благодаря его характеристикам: на нем достаточно просто писать, статическая типизация и управляемая среда позволяет исключить целый класс ошибок, присущих скриптовым языками или языкам более низкого уровня, IDE предоставляет доступ ко всем нужным инструментам в пару кликов, встроенная прямо в IDE документация и первоклассный IntelliSense.
Благодаря этому решения на C#/CLR обходятся не так дорого, как в Java.
В C# соблюдается принцип обратной совместимости, но это не мешает добавлять новые features в язык. Уже сейчас есть параметрический полиморфизм (это когда Vector), лямбда-функции и замыкания, впервые из всех языков появились LINQ (Language-integrated queries) на базе ограниченного цитирования, присутствует вывод типов, появился целый пласт DLR. В 5.0 версии появляется встроенная поддержка асинхронного программирования.
CLR/С# не так плох, как вы думаете, и это ничего не стоит проверить. Но если вам мало C#, есть F# (порт Caml) и Nemerle (гибрид C# и функционального языка), есть даже CLR C++ — берите из двух миров то, что вам надо, и совмещайте.
#. Так, алоэ, я кое-что вспомнил. О какой кросcплатформенности речь, когда чтобы запустить под Mono, мне надо всё перекомпилировать. Это же как в старом добром С, чем лучше-то?!
Очередная глупость. Я не знаю, кто вам сказал, но в целом полностью управляемое CLR-приложение, скомпилированное под Windows, НЕ НУЖНО ПЕРЕКОМПИЛИРОВАТЬ. Можно ПРОСТО перенести на Linux с установленным Mono, скомандовать mono myapp.exe, и оно запустится. И наоборот тоже работает. Я проверял.
Правда, здесь вступает в ход связывание с библиотеками. Это как gems в Ruby — если этот конкретный gem использует нативные библиотеки, то вам нужно установить эти самые нативные библиотеки. Но а вообще — полно чисто Ruby-гемов.
No magic, как-то так.
Если же вы хотите использовать общую управляемую библиотеку, то специальный механизм, называемый GAC (Global Assembly Cache), используя механизмы криптографии, позаботится об отсутствии дублирования, о том, что нужная вам библиотека — именно та и именно той версии, которую вы ждёте.
#. А вот мои знакомые программисты… Они говорили, что в комплект разработчика на Visual Studio IDE и C# входит обязательный ректальный виброзонд и инструкция по его непрерывному ношению!
OMFG O_o! Я абсолютно ответственно заявляю: ваших знакомых программистов обманули. Я бы порекомендовал вам пойти и помочь им отказаться от ношения самозваного зонда, но, боюсь, что они уже вошли во вкус и не смогут… Но ведь MS и CLR тут не при чём, так?
Выводы
Конечно, мне можно возразить. Буду рад, если кто-то захочет поправить меня или дополнить, а может быть, и опровергнуть.
В общем и целом, я рассказал, как обстоит дело, чем, надеюсь, причинил немало добра своим коллегам по цеху CLR. Надеюсь, теперь не будет дурацких вопросов, типа “зачем C#, если есть Python, а при нём GC”.
/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.