|
Взаимодействие с неуправляемым кодом
У .NET Framework масса преимуществ перед другими платформами разработки,
Однако лишь немногие компании решатся перепроектировать и заново реализовать свой код. Поэтому Microsoft встроила в CLR механизм, допускающий наличие в приложении управляемой и неуправляемой частей. CLR поддерживает три сценария взаимодействия.
• Управляемый код может вызывать неуправляемую функцию из DLL
Это обеспечивается механизмом P/Invoke (от Platform Invoke). Как-никак многие
типы, определенные в FCL, сами вызывают функции, экспортируемые библиотеками Kernel32.dll, User32.dll и др. Во многих языках реализован механизм.
упрощающий вызов неуправляемых функций, содержащихся в DLL, из управляемого кода. Так, С*- или Visual Basic-приложение может вызвать функцию
CreateSemaphore, экспортируемую Kernel32.dll.
• Управляемый код может использовать существующий СОМ-компонент
(сервер) Многие компании работают с многочисленными неуправляемыми
СОМ-компонентами. Используя библиотеку типов компонента, можно создать
управляемую сборку, описывающую СОМ-компонент. Управляемый код может
обращаться к типу в такой управляемой сборке, как к любому управляемому
типу. Подробности см. в описании утилиты Tlblmp.exe в документации МЕТ
Framework SDK. Если у вас нет библиотеки типов или нужен больший контроль над тем, что сгенерировала утилита Tlblmp.exe, вы можете вручную создать тип (в исходном коде), который CLR будет использовать для корректного взаимодействия. Например, можно задействовать СОМ-компоненты DirectX
в С#- или Visual Basic-программах.
• Неуправляемый код может использовать управляемый тип (сервер)
Масса существующего неуправляемого кода требует наличия СОМ-компонентов для своей нормальной работы. Гораздо проще реализовать их, используя
управляемый код: тогда не нужно иметь дело с подсчетом ссылок и интерфейсами. Например, можно создать элемент управления ActiveX или расширение
оболочки на С* или Visual Basic. Подробности см. в описании утилит TlbExp.exe
и RegAsm.exe в документации .NET Framework SDK.
В дополнение к этим трем сценариям компилятор Microsoft Visual C++ (версия 13) поддерживает новый ключ командной строки /clr, указывающий компилятору, что нужно генерировать IL-код, а не собственные команды х8б. Вы можете перекомпилировать имеющийся С++-код с этим новым ключом. Новый код потребует для своего выполнения CLR, и теперь вы сможете его изменить, добавляя возможности, предлагаемые CLR.
Ключ /clr не позволит скомпилировать в IL методы, содержащие встроенные
ассемблерные команды (с ключевым словом „asm), принимающие переменное
число аргументов, вызывающие setjmp или содержащие встроенные процедуры
(такие как enable, disable, .ReturnAddress и _AddressOfReturnAddress). Полный список
конструкций, которые компилятор C++ не сможет скомпилировать в IL, см. в документации по компилятору Visual C++. Когда компилятор не может скомпили-
ровать метод в IL, он компилирует его в х8б, так что приложение по-прежнему
работает,
Имейте в виду, что хотя создаваемый IL-код является управляемым, о данных
этого сказать нельзя, т. е. для объектов данных не выделяется память в управляемой куче и они не утилизируются сборщиком мусора. По сути, для типов, являющихся данными, не создаются метаданные, и имена методов таких типов искажаются.
Предыдущая стр.
Оглавление
Следующая стр.
Средняя оценка:   (1 - 1 голосов)
Для оценки необходимо зарегистрироваться
Только зарегистрировавшиеся пользователи могут оставлять комментарии
|
|