Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
OSISP Part 3.DOC
Скачиваний:
42
Добавлен:
11.05.2015
Размер:
360.45 Кб
Скачать
  1. Взаимодействие управляемого и неуправляемого кода в среде .Net на примере вызова функций Windows api.

У .NET Framework масса преимуществ перед другими платформами разработки.

Однако лишь немногие компании решатся перепроектировать и заново реализовать свой код. Поэтому Microsoft встроила в CLR механизм, допускающий наличие в приложении управляемой и неуправляемой частей. CLR поддерживает три сценария взаимодействия.

• Управляемый код может вызывать неуправляемую функцию из DLL

Это обеспечивается механизмом P/Invoke (от Platform Invoke). Как-никак многие типы, определенные в FCL, сами вызывают функции, экспортируемые библиотеками Kernel32.dll, User32.dll и др. Во многих языках реализован механизм, упрощающий вызов неуправляемых функций, содержащихся в DLL, из управляемого кода. Так, С#- или Visual Basic-приложение может вызвать функцию CreateSemaphore, экспортируемую Kernel32.dll.

• Управляемый код может использовать существующий СОМ-компонент (сервер)

Многие компании работают с многочисленными неуправляемыми СОМ-компонентами. Используя библиотеку типов компонента, можно создать управляемую сборку, описывающую СОМ-компонент. Управляемый код может обращаться к типу в такой управляемой сборке, как к любому управляемому типу. Framework SDK. Если у вас нет библиотеки типов или нужен больший контроль над тем, что сгенерировала утилита Tlblmp.exe, вы можете вручную создать тип (в исходном коде), который CLR будет использовать для корректного взаимодействия. Например, можно задействовать СОМ-компоненты DirectX в С#- или Visual Basic-программах.

• Неуправляемый код может использовать управляемый тип (сервер)

Масса существующего неуправляемого кода требует наличия СОМ-компонентов для своей нормальной работы. Гораздо проще реализовать их, используя управляемый код: тогда не нужно иметь дело с подсчетом ссылок и интерфейсами. Например, можно создать элемент управления ActiveX или расширение оболочки на С# или Visual Basic.

В дополнение к этим трем сценариям компилятор Microsoft Visual C++ (версия 13) поддерживает новый ключ командной строки /clr, указывающий компилятору, что нужно генерировать IL-код, а не собственные команды х8б. Вы можете перекомпилировать имеющийся С++-код с этим новым ключом. Новый код потребует для своего выполнения CLR, и теперь вы сможете его изменить, добавляя возможности, предлагаемые CLR.

Ключ /clr не позволит скомпилировать в IL методы, содержащие встроенные ассемблерные команды (с ключевым словом asm), принимающие переменное число аргументов, вызывающие setjmp или содержащие встроенные процедуры (такие как enable, disable, .ReturnAddress и _AddressOfReturnAddress). Полный список конструкций, которые компилятор C++ не сможет скомпилировать в IL. Когда компилятор не может скомпилировать метод в IL, он компилирует его в х8б, так что приложение по-прежнему работает. Хотя создаваемый IL-код является управляемым, о данных этого сказать нельзя, т. е. для объектов данных не выделяется память в управляемой куче и они не утилизируются сборщиком мусора. По сути, для типов, являющихся данными, не создаются метаданные, и имена методов таких типов искажаются.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]