Иллюстрированный самоучитель по Architecture .NET

Смешивание управляемого и неуправляемого кода

• Сравнение управляемого и неуправляемого кода

  Архитектура .NET поддерживает многочисленные языки программирования. В основном язык C++ выбирают из-за того, что в интерфейс 32-разрядных Windows-приложений (Win32 API), в программирование на основе модели компонентных объектов Microsoft (Component Object Model, COM) и в существующие программы были вложены большие средства.

• Причины смешивания управляемого и неуправляемого кодов. Неуправляемый или опасный?

  Если управляемые расширения C++ являются такими хорошими, тогда зачем может потребоваться создавать неуправляемый код? На этот вопрос существует несколько ответов:

• Управляемые и неуправляемые ссылки и типы значений

  Существуют фундаментальные отличия между тем, как управляемые и неуправляемые коды обрабатывают ссылки и типы значений. Неуправляемый код C++ позволяет объявлять локальные переменные, параметры методов и члены классов как относящиеся к типам, определенным неуправляемыми классами или структурами.

• Ограничения на использование управляемых типов в C++

  К сожалению, существует множество правил, которые ограничивают использование управляемых типов (классов, структур, интерфейсов), что ведет к затруднениям в работе с ними по сравнению с традиционными неуправляемыми типами в C++.

• Вызов управляемого кода из неуправляемого и обратный вызов

  Несмотря на ограничения, описанные в предыдущем разделе, есть несколько способов сотрудничества управляемого и неуправляемого кодов даже в пределах одного исходного файла. Например, приведенная ниже программа демонстрирует, что управляемый код может вызывать неуправляемый.

• Сравнение программирования на C++ с использованием модели компонентных объектов Microsoft (COM) и .NET

  Для простого и эффективного определения набора методов без определенной реализации используется управляемый интерфейс. Идея применения интерфейсов в программировании является одной из наиболее важных концепций объектно-ориентированного программирования.

• Доступ из управляемого кода к компонентам, построенным на основе модели компонентных объектов Microsoft (COM)

  Как уже было показано в предыдущем разделе, программирование компонентов .NET легко осуществить, используя управляемый код C++, но это так же легко и в любом другом языке .NET. Вероятно, никто ничего не потеряет, перейдя от надоевшей сложности программирования компонентов на основе модели компонентных объектов Microsoft (СОМ) к программированию компонентов .NET.

• Сервисная программа Tibinp.ехе

  Сервисная программа Tlbimp.ere (Type Library to .NET Assembly Converter – Транслятор (конвертер) библиотеки типов на .NET) находится в папке \Program FilesXMicrosoft.NET\FrameworkSDK\Bin. Она используется для генерации управляемых классов, которые являются упаковщиками неуправляемых классов, построенных на основе модели компонентных объектов Microsoft (COM).

• Унаследованный компонент на основе модели компонентных объектов Microsoft (COM)

  В целях демонстрации нам потребовался действующий компонент на основе модели компонентных объектов Microsoft (COM), который и будет описан в этом разделе. Заметьте, что IDL-файл LegacyCOMServer был создан как часть проекта динамически подключаемой библиотеки VC++ 6.0 (ATL СОМ AppWizard DLL).

• Действующий клиент на основе модели компонентных объектов Microsoft (COM)

  В целях сравнения (и, конечно, для тестирования компонента, построенного на основе модели компонентных объектов Microsoft (COM), до применения к нему утилиты Tlbimp.exe) ниже показано неуправляемое консольное клиентское приложение Win32.

• Создание клиента на основе модели компонентных объектов Microsoft (COM) с помощью управляемого C++

  Перед тем, как двинуться дальше и приступить к разработке программы на управляемом C++, которая сможет выступать в роли клиента для имеющегося компонента, построенного на основе модели компонентных объектов Microsoft (COM), мы создадим сборку LEGACYCOMSERVERLib.dll, применив утилиту Tlbimp.exe к файлу LegacyCOMSErver.tlb.

• Разработка управляемого клиента на основе модели компонентных объектов Microsoft (COM) с помощью С#

  В целях сравнения ниже приведена аналогичная клиентская программа на языке С#. Конечно, эта книга посвящена C++, а не С#, однако некоторые фрагменты программ на С# помещены в нее для наглядности. Программа на С# в точности соответствует программе на управляемом C++, но чуточку проще.

• Создание с помощью управляемого C++ клиента на основе модели компонентных объектов Microsoft (COM) без метаданных

  Ниже описан еще один способ вызова существующего компонента, построенного на основе модели компонентных объектов Microsoft (COM), из программы на управляемом C++. В этом способе не нужно создавать сборку упаковщика с помощью Tlbimp.exe.

• Создание с помощью С# управляемого клиента на основе модели компонентных объектов Microsoft (COM) без метаданных

  В целях сравнения предыдущая программа клиента на управляемом C++ реализована снова, теперь уже на С#. Новая реализация приведена ниже. Выдача новой программы, естественно, та же, что и у старой. Как и предыдущий пример, новая программа интересна прежде всего тем, что ей не нужна сборка из метаданных. Следовательно, не нужно ни добавлять ссылку к проекту, ни инсталлировать сборку.

• Доступ к управляемым компонентам из клиентов на основе модели компонентных объектов Microsoft (COM)

  Очевидно, что скорее всего вам потребуется создать новое приложение .NET, в котором используются существующие компоненты, основанные на модели компонентных объектов Microsoft (COM). Однако иногда может потребоваться пройтись и в другом направлении.

• Раннее связывание клиента на основе модели компонентных объектов Microsoft (COM) с компонентами .NET

  Ранне-связываемые клиенты на основе модели компонентных объектов Microsoft (СОМ) обычно используют информацию библиотеки типов для доступа к компонентам на основе модели компонентных объектов Microsoft (COM).

• Динамическое связывание клиента на основе модели компонентных объектов Microsoft (COM) с компонентами .NET

  Существующие клиенты на основе модели компонентных объектов Microsoft (COM) можно динамически связать с управляемыми компонентами, так как все управляемые типы непосредственно поддерживают стандартный интерфейс модели компонентных объектов Microsoft (COM) – IDispatch.

• Явное определение интерфейса

  В предыдущем разделе мы определили общедоступный управляемый класс ManagedClass, который автоматически был представлен интерфейсом модели компонентных объектов Microsoft (COM), сгенерированным со значением AutoDual (Автодуальный), заданным в атрибуте Classlnterface (ClassInterfaceType::AutoDual).

• Службы обращения к платформе: Plnvoke (Platform Invocation Services). Резюме.

  Службы обращения к платформе, или Plnvoke (Platform Invocation Services,), делают неуправляемые экспортируемые динамически подключаемой библиотекой (DLL) функции доступными для управляемой программы клиента.