System.Runtime.InteropServices.ComWrappers, klasa

  • Artykuł

Ten artykuł zawiera dodatkowe uwagi dotyczące dokumentacji referencyjnej dla tego interfejsu API.

Interfejs ComWrappers API zapewnia obsługę interfejsu IUnknown API niezależnie od wbudowanej obsługi współdziałania modelu COM. Interfejs ComWrappers API uwidacznia minimalną obsługę środowiska uruchomieniowego, która jest wymagana dla deweloperów, aby zastąpić wbudowaną wersję w wydajny sposób.

Tradycyjnie w środowisku uruchomieniowym natywny serwer proxy do obiektu zarządzanego jest nazywany otoką wywoływaną modelu COM (CCW), a zarządzany serwer proxy do obiektu natywnego jest nazywany otoką wywoływaną środowiska uruchomieniowego (RCW). Jednak w przypadku użycia w tym miejscu te terminy nie powinny być mylone z wbudowanymi funkcjami o tej samej nazwie (czyli CCW i RCW). W przeciwieństwie do wbudowanych funkcji większość odpowiedzialności za dokładne zarządzanie okresem istnienia, wysyłanie metod i marshalling argumentów i zwracanych wartości pozostaje do implementatora ComWrappers .

"Minimalna obsługa" jest definiowana przez następujące funkcje:

  1. Efektywne mapowanie między obiektem zarządzanym a natywnym serwerem proxy (na przykład CCW).
  2. Efektywne mapowanie między natywnym IUnknown i zarządzanym serwerem proxy (na przykład RCW).
  3. Integracja z modułem odśmiecaniem pamięci za pośrednictwem kontraktu interfejsu IReferenceTrackerHost .

Wykorzystanie tego jest zaawansowanym scenariuszem.

Stan serwera proxy

Ta sekcja zawiera opisy i ilustracje stanu natywnego i zarządzanego serwera proxy po ich utworzeniu.

Na poniższych ilustracjach silne odwołanie jest przedstawiane jako linia ciągła (===), a słabe odwołanie jest przedstawiane jako linia przerywana (= = =). Terminy "silne odwołanie" i "słabe odwołanie" powinny być interpretowane jako "przedłużające okres istnienia" i "nie przedłużające okresu istnienia", w przeciwieństwie do oznaczania konkretnej implementacji.

Poniższa ilustracja przedstawia stan obiektu zarządzanego i natywnego serwera proxy po wywołaniu metody ComWrappers.GetOrCreateComInterfaceForObject(Object, CreateComInterfaceFlags).

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

Na następnej ilustracji przedstawiono stan obiektu natywnego i zarządzanego serwera proxy po wywołaniu metody ComWrappers.GetOrCreateObjectForComInstance(IntPtr, CreateObjectFlags). Koncepcja "tożsamości" jest zgodna z regułami dla elementu IUnknown.

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

Zwróć uwagę, że z perspektywy środowiska uruchomieniowego istnieją tylko słabe odwołania. Zakłada +1 się, że liczba odwołań względem obiektu natywnego jest wykonywana przez twórcę zarządzanego serwera proxy (czyli implementatora ComWrappers ), aby zapewnić skojarzony okres istnienia między obiektem natywnym a zarządzanym serwerem proxy. Istnieje opcjonalne silne odwołanie (tj AddRef(). ) wymienione w zarządzanym serwerze proxy, które jest używane do obsługi scenariusza (3) wymienionego wcześniej. Zobacz: CreateObjectFlags.TrackerObject. W przypadku tego opcjonalnego silnego odwołania liczba odwołań będzie następująca +2: .