Маршалинг взаимодействия

Маршалирование взаимодействия определяет, как данные передаются в аргументах метода и возвращают значения между управляемой и неуправляемой памятью во время вызовов. Маршалирование взаимодействия — это действие во время выполнения, выполняемое службой маршаллинга среды cl language.

Представление большинства типов данных является общим как в управляемой, так и в неуправляемой памяти. Маршаллировщик взаимодействия обрабатывает эти типы. Другие типы могут иметь неоднозначное представление или могут вообще не быть представленными в управляемой памяти.

У неоднозначного типа может либо быть несколько представлений в неуправляемом коде, сопоставленных с одним управляемым типом, либо у него могут отсутствовать сведения о типе, такие как размер массива. Для неоднозначных типов маршаллизатор предоставляет представление по умолчанию и альтернативные представления, в которых существует несколько представлений. Вы можете указать явные инструкции маршалеру о том, как маршалировать неоднозначный тип.

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

Среда CLR предоставляет два механизма взаимодействия с неуправляемым кодом.

  • Вызов неуправляемого кода, позволяющий управляемому коду вызывать функции, экспортированные из неуправляемой библиотеки.
  • COM-взаимодействие, позволяющее управляемому коду взаимодействовать с COM-объектами с помощью интерфейсов.

Вызовы платформы и com-взаимодействия используют маршалинг взаимодействия для точного перемещения аргументов метода между вызывающим и вызывающим и обратно, если это необходимо. Как показано на схеме ниже, за исключением использования функций обратного вызова метод вызова неуправляемого кода всегда вызывается в направлении от управляемого к неуправляемому коду, а не наоборот. Хотя вызовы неуправляемого кода могут выполняться только от управляемого к неуправляемому коду, данные могут передаваться в обоих направлениях в виде параметров ввода или вывода. Вызовы метода COM-взаимодействия могут проходить в обоих направлениях.

Platform invoke

На самом низком уровне оба механизма используют одну и ту же службу маршалинга взаимодействия; однако некоторые типы данных поддерживаются исключительно вызовом COM-взаимодействия или платформы. Дополнительные сведения см. в разделе "Поведение маршаллинга по умолчанию".

Маршаллинг и com-квартиры

Маршализатор взаимодействия маршалирует данные между кучей среды CLAP и неуправляемой кучей. Маршаллирование происходит всякий раз, когда вызывающий и вызывающий не могут работать с тем же экземпляром данных. Маршализатор взаимодействия позволяет вызывающему и вызывающему объекту работать с теми же данными, даже если у них есть собственная копия данных.

COM также имеет маршализатор, который маршалирует данные между квартирами COM или различными процессами COM. При вызове управляемого и неуправляемого кода в одной квартире COM маршализатор взаимодействия является единственным маршаллировщиком. При вызове управляемого кода и неуправляемого кода в другой com-квартире или другом процессе задействованы маршализатор взаимодействия и маршализатор COM.

Клиенты COM и управляемые серверы

Для экспортированного управляемого сервера с библиотекой типов, зарегистрированной с помощью средства регистрации сборок (Regasm.exe), существует запись реестра ThreadingModel со значением Both. Это значение показывает, что данный сервер можно активировать как в однопотоковом подразделении (STA), так и в многопотоковом подразделении (MTA). Как показано в таблице ниже, серверный объект создается в том же подразделении, что и вызывающий объект.

Клиент COM Сервер .NET Требования маршаллинга
STA Both становится STA. Маршаллинг с одной квартирой.
MTA Both становится MTA. Маршаллинг с одной квартирой.

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

Interop marshalling between managed and unmanaged heaps

Если планируется экспортировать управляемый сервер, учтите, что клиент COM определяет подразделение сервера. Управляемый сервер, вызванный клиентом COM, инициализированным в многопотоковом подразделении, должен обеспечить потокобезопасность.

Управляемые клиенты и COM-серверы

По умолчанию для управляемого клиента используется многопотоковое подразделение, однако тип приложения клиента .NET может изменить эту настройку. Например, для клиента Visual Basic настроено однопотоковое подразделение. Для проверки и изменения настройки подразделения для управляемого клиента можно использовать атрибут System.STAThreadAttribute, атрибут System.MTAThreadAttribute, свойство Thread.ApartmentState или свойство Page.AspCompatMode.

Автор компонента настраивает сходство потоков COM-сервера. В таблице ниже показаны сочетания параметров подразделения для клиентов .NET и COM-серверов. В нем также показаны полученные требования к маршалингу для сочетаний.

Клиент .NET COM-сервер Требования маршаллинга
MTA (по умолчанию) MTA

STA
Маршалирование взаимодействия.

Взаимодействие и маршаллинг COM.
STA MTA

STA
Взаимодействие и маршаллинг COM.

Маршалирование взаимодействия.

Когда управляемый клиент и неуправляемый сервер находятся в одной квартире, служба маршаллинга взаимодействия обрабатывает все данные маршалинга. Однако при инициализации клиента и сервера в разных квартирах также требуется маршализация COM. На следующем рисунке показаны элементы вызова между подразделениями.

Cross-apartment call between a .NET client and COM object

Для маршаллинга между квартирами можно выполнить следующие действия:

  • Примите расходы на маршаллинг между квартирами, что заметно только при наличии большого количества вызовов через границу. Чтобы вызовы успешно пересекали границу подразделения, необходимо зарегистрировать библиотеку типов COM-компонента.

  • Изменить основной поток, выбрав для клиентского потока однопотоковое или многопотоковое подразделение. Например, если клиент C# вызывает множество com-компонентов STA, можно избежать маршаллинга между квартирами, установив основной поток на STA.

    Примечание.

    После установки потока клиента C# вызовы к com-компонентам MTA потребуют маршаллинга между квартирами.

Инструкции по выбору модели подразделения в явном виде см. в разделе Управляемые и неуправляемые потоки.

Маршаллирование удаленных вызовов

Как и при маршаллингах между квартирами, маршалирование COM участвует в каждом вызове управляемого и неуправляемого кода всякий раз, когда объекты находятся в отдельных процессах. Например:

  • Клиент COM, обращающийся к управляемому серверу на удаленном компьютере, использует DCOM.
  • Управляемый клиент, обращающийся к СОМ-серверу на удаленном компьютере, использует DCOM.

На следующем рисунке показано, как маршалирование взаимодействия и маршалирование COM обеспечивают каналы связи между процессами и границами узлов:

Cross-process marshalling

Сохранение идентификаторов

Среда CLR сохраняет идентификаторы управляемых и неуправляемых ссылок. На схеме ниже показан поток прямых неуправляемых ссылок (верхняя строка) и прямых управляемых ссылок (нижняя строка) через границы между процессами и узлами.

COM callable wrapper and runtime callable wrapper

На этой схеме:

  • Неуправляемый клиент получает ссылку на COM-объект от управляемого объекта, получившего эту ссылку от удаленного узла. Механизмом удаленного взаимодействия является DCOM.

  • Управляемый клиент получает ссылку на управляемый объект от COM-объекта, получившего эту ссылку от удаленного узла. Механизмом удаленного взаимодействия является DCOM.

    Примечание.

    Экспортированная библиотека типов управляемого сервера должна быть зарегистрирована.

Число границ процессов между вызывающим и вызываемым объектами несущественно; одни и те же прямые ссылки используются для вызовов, входящих в процессы и исходящих из них.

Управляемое удаленное взаимодействие

Среда выполнения также обеспечивает управляемое удаленное взаимодействие, которое можно использовать для установления канала связи между управляемыми объектами через границы между процессами и узлами. Управляемое удаленное взаимодействие может предусматривать брандмауэр между взаимодействующими компонентами, как показано на следующем рисунке.

SOAP or TcpChannel Удаленные вызовы между брандмауэрами с помощью SOAP или класса TcpChannel

Некоторые неуправляемые вызовы, например вызовы между обслуживаемыми COM-компонентами, могут проводиться через SOAP.

Заголовок Description
Поведение маршаллинга по умолчанию Описывает правила, которые служба маршаллинга взаимодействия использует для маршалирования данных.
Маршаллирование данных с помощью вызова платформы Описывается способ объявления параметров метода и передачи аргументов в функции, экспортируемые неуправляемыми библиотеками.
Маршаллирование данных с помощью COM-взаимодействия Описывает, как настроить COM-оболочки для изменения поведения маршаллинга.
Практическое руководство. Миграция DCOM с управляемым кодом в WCF Описывается переход с модели DCOM на WCF.
Практическое руководство. Сопоставление значений HRESULT и исключений Описывается, как сопоставить настраиваемые исключения со значениями HRESULT, и приводится полный перечень сопоставлений значений HRESULT с соответствующими классами исключений платформы .NET Framework.
Взаимодействие с помощью универсальных типов Описываются действия, поддерживаемые при использовании универсальных типов для взаимодействия COM.
Взаимодействие с неуправляемым кодом Описываются службы взаимодействия, предоставляемые средой CLR.
Расширенное COM-взаимодействие Приводятся ссылки на дополнительные сведения о включении COM-компонентов в разрабатываемое приложение .NET Framework.
Вопросы разработки для взаимодействия Приводятся советы по написанию кода встроенных COM-компонентов.

Справочные материалы

System.Runtime.InteropServices