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

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

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

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

Модели вызова платформы и COM-межоперабельности

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

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

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

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

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

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

COM также имеет компонент маршалирования, который передаёт данные между апартаментами COM или различными процессами COM. При вызове между управляемым и неуправляемым кодом в рамках одного компонентного объектного модельного апартамента (COM) маршализатор взаимодействия является единственным вовлечённым маршализатором. При вызове между управляемым и неуправляемым кодом в другой COM-квартире или другом процессе участвуют интероп-маршализатор и COM-маршализатор.

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

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

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

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

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

Значением по умолчанию для управляемых клиентских квартир является MTA; Однако тип приложения клиента .NET может изменить параметр по умолчанию. Например, параметром квартиры клиента Visual Basic является STA. Можно использовать свойство System.STAThreadAttribute, свойство System.MTAThreadAttribute, свойство Thread.ApartmentState или свойство Page.AspCompatMode для проверки и изменения параметров помещения управляемого клиента.

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

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

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

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

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

  Замечание

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

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

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

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

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

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

Сохранение удостоверения

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

На этой иллюстрации:

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

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

  Замечание

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

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

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

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

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

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

Связанные разделы

Справка

System.Runtime.InteropServices