Что такое управляемый код и clr основные требования к управляемому коду
Процесс выполнения управляемого кода
Процесс управляемого исполнения включает следующие шаги, которые подробно разбираются позднее в этом разделе:
Чтобы воспользоваться преимуществами среды CLR, необходимо использовать один или несколько языковых компиляторов, обращающихся к среде выполнения.
При компиляции исходный код преобразуется в MSIL и создаются необходимые метаданные.
Во время выполнения JIT-компилятор преобразует инструкции MSIL в машинный код. Во время этой компиляции выполняется проверка кода и метаданных MSIL с целью установить, можно ли для них определить, является ли код типобезопасным.
Среда CLR предоставляет инфраструктуру, обеспечивающую выполнение кода, и ряд служб, которые можно использовать при выполнении.
Выбор компилятора
Чтобы воспользоваться преимуществами, предоставляемыми средой CLR, необходимо применить один или несколько языковых компиляторов, ориентированных на среду выполнения, например компилятор Visual Basic, C#, Visual C++, F# или один из многочисленных компиляторов от независимых разработчиков, например компилятор Eiffel, Perl или COBOL.
Поскольку среда выполнения является многоязычной, она поддерживает широкий набор разнообразных типов данных и языковых средств. Доступные средства среды выполнения определяются используемым языковым компилятором, и разработчики создают код с использованием этих средств. Используемый в коде синтаксис определяется компилятором, а не средой выполнения. Если компонент должен быть полностью доступен для компонентов, написанных на других языках, то экспортируемые этим компонентом типы должны предоставлять исключительно языковые функции, включенные в состав спецификации CLS. Атрибут CLSCompliantAttribute позволяет гарантировать, что код является CLS-совместимым. Дополнительные сведения см. в разделе Независимость от языка и независимые от языка компоненты.
Компиляция в MSIL
При компиляции в управляемый код компилятор преобразует исходный код в промежуточный язык Microsoft (MSIL), представляющий собой независимый от процессора набор инструкций, который можно эффективно преобразовать в машинный код. Язык MSIL включает инструкции для загрузки, сохранения, инициализации и вызова методов для объектов, а также инструкции для арифметических и логических операций, потоков управления, прямого доступа к памяти, обработки исключений и других операций. Перед выполнением код MSIL необходимо преобразовать в код для конкретного процессора, обычно с помощью JIT-компилятора. Поскольку среда CLR предоставляет для каждой поддерживаемой компьютерной архитектуры один или несколько JIT-компиляторов, один набор инструкций MSIL можно компилировать и выполнять в любой поддерживаемой архитектуре.
Когда компилятор создает код MSIL, одновременно создаются метаданные. Метаданные содержат описание типов в коде, включая определение каждого типа, сигнатуры каждого члена типа, члены, на которые есть ссылки в коде, а также другие сведения, используемые средой выполнения во время выполнения. MSIL и метаданные содержатся в переносимом исполняемом (PE) файле, который основывается на форматах Microsoft PE и COFF, ранее использовавшихся для исполняемого контента, но при этом расширяет их возможности. Этот формат файлов, позволяющий размещать код MSIL или машинный код, а также метаданные, позволяет операционной системе распознавать образы среды CLR. Наличие в файле метаданных наряду с MSIL позволяет коду описывать себя. Это устраняет потребность в библиотеках типов и языке IDL. Среда выполнения находит и извлекает метаданные из файла по мере необходимости при выполнении.
Компиляция инструкций MSIL в машинный код
Компиляция с помощью JIT-компилятора
При JIT-компиляции язык MSIL преобразуется в машинный код во время выполнения приложения по требованию, когда загружается и выполняется содержимое сборки. Поскольку среда CLR предоставляет JIT-компилятор для каждой поддерживаемой архитектуры процессора, разработчики могут создавать набор сборок MSIL, которые могут компилироваться с помощью JIT-компилятора и выполняться на разных компьютерах с разной архитектурой. Если управляемый код вызывает специфический для платформы машинный API или библиотеку классов, то он будет выполняться только в соответствующей операционной системе.
При JIT-компиляции учитывается возможность того, что определенный код может никогда не вызываться во время выполнения. Чтобы не тратить время и память на преобразование всего содержащегося в PE-файле MSIL в машинный код, при компиляции MSIL преобразуется в машинный код по мере необходимости во время выполнения. Полученный таким образом машинный код сохраняется в памяти, что позволяет использовать его при дальнейших вызовах в контексте этого процесса. Загрузчик создает и присоединяет заглушки к каждому методу в типе, когда тип загружается и инициализируется. При первом вызове метода заглушка передает управление JIT-компилятору, который преобразует MSIL для этого метода в машинный код и заменяет заглушку на созданный машинный код. Поэтому последующие вызовы метода, скомпилированного с помощью JIT-компилятора, ведут непосредственно к машинному коду.
Создание кода во время установки с помощью NGen.exe
Тот факт, что JIT-компилятор преобразует MSIL-код сборки в машинный код при вызове отдельных методов, определенных в этой сборке, отрицательно сказывается на производительности во время выполнения. В большинстве случаев снижение производительности приемлемо. Что более важно, код, созданный JIT-компилятором, будет привязан к процессу, вызвавшему компиляцию. Его нельзя сделать общим для нескольких процессов. Чтобы созданный код можно было использовать в нескольких вызовах приложения или в нескольких процессах, которые совместно используют набор сборок, среда CLR предоставляет режим предварительной компиляции. В таком режиме компиляции для преобразования сборок MSIL в машинный код в стиле JIT-компилятора используется генератор образов в машинном коде (Ngen.exe). Однако, работа Ngen.exe отличается от JIT-компилятора в трех аспектах.
Ngen.exe выполняет преобразование из MSIL-кода в машинный код перед выполнением приложения, а не во время его выполнения.
При этом сборка компилируется целиком, а не по одному методу за раз.
Она сохраняет созданный код в кэше образа машинного кода в виде файла на диске.
Проверка кода
В процессе компиляции в машинный код MSIL-код должен пройти проверку, если только администратор не установил политику безопасности, разрешающую пропустить проверку кода. MSIL-код и метаданные проверяются на типобезопасность. Это подразумевает, что код должен обращаться только к тем адресам памяти, к которым ему разрешен доступ. Типобезопасность помогает изолировать объекты друг от друга и способствует их защите от непредумышленного или злонамеренного повреждения. Она также гарантирует надежное применение условий безопасности для кода.
Среда выполнения основывается на истинности следующих утверждений для поддающегося проверке типобезопасного кода:
ссылка на тип строго совместима с адресуемым типом;
для объекта вызываются только правильно определенные операции;
удостоверения являются подлинными.
В процессе проверки кода MSIL делается попытка подтвердить, что код может получать доступ к расположениям в памяти и вызывать методы только через правильно определенные типы. Например, код не должен разрешать доступ к полям объекта так, чтобы можно было выходить за границы расположения в памяти. Кроме того, проверка определяет, правильно ли был создан код MSIL, поскольку неверный код MSIL может приводить к нарушению правил строгой типизации. В процессе проверки передается правильно определенный типобезопасный код. Однако иногда типобезопасный код может не пройти проверку из-за ограничений процесса проверки, а некоторые языки по своей структуре не позволяют создавать поддающийся проверке типобезопасный код. Если в соответствии с политикой безопасности использование типобезопасного кода является обязательным и код не проходит проверку, то при выполнении кода создается исключение.
Выполнение кода
Среда CLR предоставляет инфраструктуру, обеспечивающую управляемое выполнение кода, и ряд служб, которые можно использовать при выполнении. Перед выполнением метода его необходимо скомпилировать в код для конкретного процессора. Каждый метод, для которого создан MSIL-код, компилируется с помощью JIT-компилятора при первом вызове и затем запускается. При следующем вызове метода будет выполняться существующий JIT-скомпилированный код. Процесс JIT-компиляции и последующего выполнения кода повторяется до завершения выполнения.
Во время выполнения для управляемого кода доступны такие службы, как сборка мусора, обеспечение безопасности, взаимодействие с неуправляемым кодом, поддержка отладки на нескольких языках, а также поддержка расширенного развертывания и управления версиями.
В Microsoft Windows Vista загрузчик операционной системы выполняет поиск управляемых модулей, анализируя бит в заголовке COFF. Установленный бит обозначает управляемый модуль. При обнаружении управляемых модулей загружается библиотека Mscoree.dll, а подпрограммы _CorValidateImage и _CorImageUnloading уведомляют загрузчик о загрузке и выгрузке образов управляемых модулей. Подпрограмма _CorValidateImage выполняет следующие действия:
Проверяет, является ли код допустимым управляемым кодом.
Заменяет точку входа в образе на точку входа в среде выполнения.
В 64-разрядных системах Windows _CorValidateImage изменяет образ, находящийся в памяти, путем преобразования его из формата PE32 в формат PE32+.
Что такое управляемый/неуправляемый код в C#?
что такое управляемый и неуправляемый код? Я не понимаю.
12 ответов
некоторый код библиотеки должен вызывать неуправляемый код (например, API собственного кода, например Win32). Поскольку это означает выход за пределы периметра безопасности для управляемого кода, необходимо соблюдать осторожность.
вот еще одно бесплатное объяснение управляемого кода:
Я думаю, это потому, что NUnit выполняет ваш код для UnitTesting и может иметь некоторую его часть, которая неуправляема. Но я не уверен, поэтому не принимайте это за золото. Я уверен, что кто-то сможет дать вам больше информации об этом. Надеюсь, это поможет!
этой хорошая статья о предмете.
уроженца код часто является синонимом неуправляемого, но не идентичен.
когда вы думаете о неуправляемые, думайте машин-специфический, машин-ровный код. Как ассемблере x86. Неуправляемый (родной) код компилируется и связывается для запуска непосредственно на процессоре, для которого он был разработан, исключая все ОС на данный момент. Он не переносной, но быстрый. Очень простой, урезанный код.
в нескольких словах, как это возможно:
NUnit загружает модульные тесты в отдельный AppDomain, и я предполагаю, что точка входа не вызывается (вероятно, не требуется), поэтому сборка записи равна null.
Управляемый Код:
Код, который работает по «договору о сотрудничестве» с общеязыковая среда выполнения. Управляемый код должен предоставлять метаданные необходимые для выполнения оказания услуг, таких как память управления, межъязыковая интеграция, код доступа, и автоматический контроль времени жизни объектов. Весь код на основе Microsoft промежуточный язык (MSIL) выполняется как управляемый код.
ООН-Управляемый Код:
Созданный код без учета соглашения и требования среды выполнения common language. Неуправляемый код выполняется в среде CLR с минимальными службы (например, нет сборки мусора, ограниченная отладка и т. д.).
OTOH,unmanged code что-то специфическое к машине и подготавливает для использования, никакая потребность обрабатывать ее более далее.
Взаимодействие управляемого и неуправляемого кода
Автор: Сергей Тепляков
ООО НПП Кронос
Источник: RSDN Magazine #3-2008
Опубликовано: 12.02.2009
Исправлено: 10.12.2016
Версия текста: 1.0
Введение
В данной статье я опишу общие принципы решения задачи обращения из неуправляемого кода к управляемому, а также реализую оболочку для работы с распространенной библиотекой log4net.
1 Общие принципы
Реализация смешанных приложений (т.е. содержащих управляемый и неуправляемый код) основана на том, что среда CLR поддерживает конструкции, не входящие в общую систему типов CLR, путем указания того, что некоторый тип является непрозрачным (opaque type). Метаданные непрозрачных типов не содержат никакой дополнительной информации о типе, вместо этого хранится только размер экземпляра в памяти.
Поскольку среда CLR ничего не знает о полях непрозрачных типов, возникают проблемы при работе со ссылками на управляемые объекты.
При попытке компиляции этого кода вы получите следующее сообщение об ошибке: “error C3265: cannot declare a managed ‘managed_’ in an unmanaged OpaqueObject”. Проблема в том, что управляемый объект располагается в управляемой куче, и сборщик мусора никак не может узнать о том, что где-то в неуправляемой памяти осталась ссылка на этот объект. Если бы компиляция и выполнение этого кода были возможны, то в произвольный момент времени (после сборки мусора) в неуправляемой памяти остался бы указатель на удаленный объект. А вы ведь знаете, к чему приводит разыменовывание указателя, который указывает на удаленный объект?
Для решения этой проблемы среда CLR предоставляет тип System::Runtime::InteropServices::GCHandle, который поддерживает работу со ссылками на управляемые объекты из неуправляемой памяти. Для создания нового экземпляра GCHandle применяется статическая функция GCHandle::Alloc. В результате выполнения этой функции создается новая ссылка на управляемый объект, и дескриптор ссылки сохраняется в экземпляре типа GCHandle. Тип GCHandle поддерживает полный перечень типов ссылок на управляемый объект, включая слабые (weak references) и зафиксированные (pinned references) ссылки. Любая программа может преобразовать тип GCHandle в IntPtr (который можно безопасно хранить в непрозрачном типе) и обратно. Экземпляр типа GCHandle (и ссылка на управляемый объект) существуют до тех пор, пока не будет явно вызван метод GCHandle.Free.
Приведенный ниже С++-класс демонстрирует использование типа GCHandle для взаимодействия управляемого и неуправляемого кода.
Как видите, получить доступ к управляемому коду из неуправляемого не так и сложно. Но для того, чтобы этот доступ был возможен при компиляции приложения без ключа /clr, придется немного потрудиться.
2 Доступ к управляемому коду из неуправляемого
В предыдущем разделе описаны основные принципы взаимодействия управляемого и неуправляемого кода. Но все примеры компилировались с ключом компилятора /clr, но как быть, если это невозможно? Что делать, если имеется консольное Win32-приложение, служба или приложение, разработанное с использованием MFC, но нет возможности перекомпилировать его с ключом /clr?
Рисунок 1. Взаимодействие управляемого и неуправляемого кода.
Для начала рассмотрим набор управляемых классов, написанных на языке C#.
Этот класс ничего не делает, это всего лишь пример, с помощью которого можно проверить взаимодействие управляемого и неуправляемого кода.
Класс Class2 также не слишком сложен, но он принимает другой управляемый класс в качестве параметра конструктора.
Этот код компилируется и прекрасно работает, но для его компиляции необходимо использовать ключ /clr, поэтому он не может быть использован в неуправляемом приложением.
Для решения этой проблемы можно воспользоваться тем, что gcroot является тонкой оболочкой над указателем, и единственным членом этого класса является intptr_t. Поэтому экземпляр класса gcroot и intptr_t гарантированно имеют одинаковое представление в памяти.
Другой особенностью управляемых приложений является то, что при их компиляции константа _MANAGED определена и равна 1.
При всем этом класс ManagedObject будет выглядеть следующим образом.
Но проблема еще решена не полностью. Дело в том, что когда клиент из неуправляемого кода создает экземпляр класса ManagedObject, компилятор автоматически генерирует встроенные функции конструктора копирования и оператора присваивания, которые реализуют побитовое копирование объекта. Но побитовое копирование intptr_t приведет к тому, что два объекта gcroot будут содержать один и тот же дескриптор управляемого объекта. В таком случае при удалении второго экземпляра gcroot вы получите неопределенное поведение, что в большинстве случаев выражается в нарушении доступа к памяти.
Решение задачи состоит в том, чтобы объявить экспортируемые функции конструктора копирования и оператора присваивания в заголовочном файле, а реализовать их в соответствующем cpp-файле.
Тогда, если в неуправляемом коде встретится выражение следующего вида:
С помощью класса ManagedWrapper написать оболочку управляемого класса не составит труда. Но лучше создать несколько макросов, ускоряющих этот процесс.
При наличии класса-оболочки управляемого объекта и макроса DECLARE_WRAPPER реализация оболочки над Class1 становится тривиальной.
Ненамного сложнее оболочка для класса Class2.
Использовать классы оболочек достаточно просто.
В результате выполнения этого кода получим следующий результат (рисунок 2).
Рисунок 2. Работа с классами-оболочками из неуправляемого кода.
Во время разработки смешанных приложений я столкнулся с проблемой отладки. Для отладки dll-оболочки из неуправляемого приложения необходимо установить значение DebuggerType в Mixed. Значение по умолчанию (Auto) определяет тип загружаемого отладчика по EXE-файлу, поэтому при запуске неуправляемого EXE-файла IDE запускает неуправляемый отладчик, и отлаживать управляемый код нельзя. А когда вы указываете значение Mixed, IDE загружает оба отладчика, и проблемы с отладкой управляемых модулей не возникает.
3 Обработка исключений
При создании оболочек над классами Class1 и Class2 не была учтена одна важная деталь – обработка исключений. А что будет, если операция в управляемом коде завершится неудачно и будет сгенерировано исключение? Ответ простой – приложение «рухнет».
Рассмотрим класс Class3, который определяет свойство Age, причем значение этого свойства проверяется при установке, и, если оно больше 150 или меньше 0, генерируется исключение System::AgrumentException.
Первое, что нужно сделать – это определить неуправляемый класс исключения, который будет в управляемом коде принимать System::ArgumentException в качестве параметра и предоставлять текстовое описание ошибки для неуправляемого кода.
Все, что нужно сделать в Class3Wrapper – в функции SetAge() перехватить управляемое исключение и сгенерировать соответствующее неуправляемое исключение. Если функция в управляемом коде может генерировать несколько исключений, то нужно создать оболочки для всех этих исключений, или просто перехватить исключение System::Exception. Это уже зависит от потребностей вашего приложения.
Class3Wrapper используется аналогично любому неуправляемому классу, функция которого может генерировать исключение.
4 Работа с делегатами
Рассмотрим класс Class4, который реализует событие SampleEvent.
Там, где в управляемом коде используются делегаты, в неуправляемом коде применяются различные варианты обратного вызова. В С++ это могут быть указатели на функцию, указатели на функцию-член, boost::function (а теперь уже и std::tr1::function, для этого нужно скачать с сайта Microsoft Visual C++ 2008 Feature Pack) или любой другой функциональный объект.
Для простоты я воспользовался указателем на функцию, вы же в реальном приложении можете воспользоваться любым другим вариантом, на ваше усмотрение.
К сожалению, без определения дополнительного управляемого класса никак не обойтись. Это связано с тем, что при создании делегата нужно передать указатель на функцию-член управляемого класса. Указатель на неуправляемую функцию не может быть передан в качестве аргумента.
С использованием вспомогательных макросов, Class4Wrapper будет реализован следующим образом.
5 Оболочка над log4net
Реализация оболочки для работы с log4net достаточно проста, и не использует все описанные в данной статье возможности. Это связано с тем, что функции работы с логами не генерируют исключения и не реализуют события. Кроме того, для нормальной работы с log4net мне достаточно обернуть всего лишь три класса, причем два из них содержат только статические функции.
Прежде всего, нужно создать оболочку над интерфейсом log4net::ILog.
Реализация оболочек над log4net::LogManager и log4net::Config::XmlConfigurator еще проще, т.к. эти классы состоят только из статических функций.
Применение оболочки над log4net также достаточно простое.
Результат выполнения программы показан на рисунке 3.
Рисунок 3. Работа с log4net из неуправляемого кода.
Конечно, это не вся функциональность библиотеки log4net, которая может вам понадобиться. Но с помощью класса ManagedObject достаточно просто создать оболочки над другими классами.
Заключение
Управляемый и неуправляемый код.
Создание проекта.
Рисунок 1.1 Стартовое окно Microsoft Visual Studio 2005.
На экране появится диалоговое окно «New Project» (рисунок 1.2), где следует задать необходимые параметры проекта: тип проекта (Project types), шаблон (Templates), имя проекта (Name), расположение во внешней памяти (Location) и наименование решения (Solution Name). Флажок Create directory for solution оставить включенным.
Рисунок 1.2 Диалоговое окно задания параметров нового проекта
В результате выполненных действий в окне проводника Solution Explorer появится структура созданного проекта и откроется модуль Program.cs (рисунок 1.3).
Рисунок 1.3 Созданный проект в развернутом виде
Теперь можно приступать к программированию.
Пример 1. Простейшая программа на языке C# выглядит следующим образом:
static void Main(string[] args)
// Вывод предложения на экран
Анатомия программы.
Пространство имен в С# представляет собой совокупность связанных типов. Некоторые пространства имен, например, System, очень велики и могут включать более 100 разного рода типов; другие пространства имен, например, System.Timers, содержат всего по несколько типов. Типы DateTime и Math входят в пространство имен System.
Использование пространств имен (также называемых пакетами, библиотеками или интерфейсами прикладного программирования, API от Application Programming Interface) — это практическая реализация концепции повторного использования, принципа, чрезвычайно поощряемого в современной программной инженерии.
В качестве имени пространства имен может служить любой допустимый идентификатор, имя также может содержать точки. Пространства имен могут содержать внутри себя вложенные пространства имен, классы, структуры, и пр.
Программа в примере начинается с заявления, что она собирается использовать пространство имен System, в частности, класс System.Console, содержащий методы для работы с консолью.
Внутри пространства имен Lab_1 объявляется класс Program вместе с его содержимым вслед за открывающей фигурной скобкой. Имена файла и программы (т. е. имя класса) не обязательно должны совпадать, хотя обычно они или одинаковы, или схожи. В языке C# отсутствуют глобальные переменные и функции, поэтому все объявления переменных и функций должны находиться внутри объявления класса (количество классов неограниченно).
В структуре класса прежде всего вводится метод Main, являющийся стартовой точкой (точкой входа) в приложение. Функция должна быть объявлена как статическая, так как в этом случае для вызова функции не требуется создавать объект класса.
Содержательные действия программы ограничивается выводом на экран некоторого текста и ожидания нажатия любой клавиши. Вывод осуществляется с помощью метода Console.WriteLine; для ожидания нажатия клавиши используется метод Console.ReadKey.
В языке C# нет заголовочных файлов. Все методы для работы с консолью содержатся в классе Console пространства имен System. Метод вызывается оператором принадлежности (.). Иными словами, чтобы вызвать WriteLine() объекта Console, следует написать Corsole. WriteLine(…), поставив вместо многоточия выводимую строку.
Запуск программы осуществляется выполнением команды меню Debug ® Start Debugging, или нажатием клавиши F5. Если в компилятор не обнаружил ошибок, то на экран выводится консольное окно с результатом работы программы (рисунок 1.4).
Рисунок 1.4 Консоль с результатами выполнения программы
Пример 2. Пусть необходимо вычислить значение функции y:
Некорректные ситуации при вычислении возможны, если: 
, 
, 
.
Фрагмент кода C#, который реализует вычисление функции, представлен ниже.
y = Math.Pow(x, 2); // Вычисление y = x^2
if ((x == 0) || (b 2
1. Создать консольное приложение так, как показано в примере 1.
2. Запустить программу и убедиться в корректности ее выполнения.
3. Дополнить функцию Main кодом, который вычисляет значение математической функции y в соответствии с индивидуальным заданием и выводит его на консоль. Значения аргументов задать явным присваиванием констант. При невозможности вычисления вывести на консоль сообщение.
4. Составить блок-схему алгоритма функции Main.
5. Выполнить контрольный просчет и сделать вывод.
Таблица 1.1 Варианты заданий:
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 | |  |
— тема, цель, задание, в том числе индивидуальная часть и номер варианта;
— консольное окно с результатами работы программы;