Поделиться через

Класс System.Runtime.InteropServices.ComWrappers

В этой статье приводятся дополнительные замечания к справочной документации по этому API.

API ComWrappers обеспечивает поддержку IUnknown API независимо от встроенной поддержки взаимодействия COM. ComWrappers API предоставляет минимальную поддержку среды выполнения, необходимую разработчикам для эффективной замены встроенной версии.

Традиционно в среде выполнения нативный прокси для управляемого объекта называется COM Callable Wrapper (CCW), а управляемый прокси для нативного объекта называется Runtime Callable Wrapper (RCW). Однако при использовании здесь эти термины не следует путать со встроенными функциями того же имени (т. е. CCW и RCW). В отличие от встроенных функций, большая часть ответственности за точное управление временем жизни, управление методами и маршаллирование аргументов и возвращаемых значений ложится на исполнителя ComWrappers.

"Минимальная поддержка" определяется следующими функциями:

  1. Эффективное сопоставление между управляемым объектом и собственным прокси-сервером (например, CCW).
  2. Эффективное сопоставление между собственным IUnknown и управляемым прокси-сервером (например, RCW).
  3. Интеграция с сборщиком мусора через интерфейсный контракт IReferenceTrackerHost.

Использование этого сценария — это расширенный сценарий.

Состояние прокси-сервера

В этом разделе приведены описания и иллюстрации собственного и управляемого прокси-состояния после их создания.

На следующих иллюстрациях сильные ссылки изображаются как сплошная линия (===) и слабая ссылка отображается как дефисированная линия (= = =). Термины "строгая ссылка" и "слабая ссылка" должны интерпретироваться как "продление срока службы" и "не продление срока службы", а не указывая на конкретную реализацию.

На следующем рисунке показано состояние управляемого объекта и собственного прокси-сервера после вызова ComWrappers.GetOrCreateComInterfaceForObject(Object, CreateComInterfaceFlags).

 --------------------                  ----------------------
|   Managed object   |                |     Native proxy     |
|                    |                | Ref count: 1         |
|  ----------------  |                |  ------------------  |
| | Weak reference |=| = = = = = = = >| | Strong reference | |
| |    to proxy    | |<===============|=|    to object     | |
|  ----------------  |                |  ------------------  |
 --------------------                  ----------------------

На следующем рисунке показано состояние собственного объекта и управляемого прокси-сервера после вызова ComWrappers.GetOrCreateObjectForComInstance(IntPtr, CreateObjectFlags). Концепция "идентичность" соответствует правилам IUnknown.

 ------------------               ------------------
|  Native object   |< = = = = = =|                  |
| Ref count: +1    |             | Mapping from     |
 ------------------              | native identity  |
 ------------------------        | to managed proxy |
|   Managed proxy        |< = = =|                  |
| Created by ComWrappers |        ------------------
|   implementer.        |
| Optional AddRef() on   |
|   native object.      |
 ------------------------

Обратите внимание, что с точки зрения среды выполнения существуют только слабые ссылки. Предполагается, что учет ссылок на нативный объект ведется создателем управляемого прокси-сервера (т. е. реализатором), чтобы обеспечить связанное время жизни между нативным объектом и его управляемым прокси-сервером. Существует необязательная надежная ссылка (то есть AddRef()), которая упоминается в управляемой прокси-сервере и используется для поддержки упомянутого ранее сценария (3). См. CreateObjectFlags.TrackerObject. При использовании этой необязательной строгой ссылки число ссылок будет +2.