Przeprowadzanie marshalingu międzyoperacyjnej

Interop marshalling określa sposób przekazywania danych w argumentach metody i zwracania wartości między zarządzaną i niezarządzaną pamięcią podczas wywołań. Interop marshalling to działanie środowiska uruchomieniowego wykonywane przez usługę marshalling środowiska uruchomieniowego języka wspólnego.

Większość typów danych ma typowe reprezentacje zarówno w pamięci zarządzanej, jak i niezarządzanej. Marshaller międzyoperacyjny obsługuje te typy za Ciebie. Inne typy mogą być niejednoznaczne lub nie są reprezentowane w pamięci zarządzanej.

Niejednoznaczny typ może mieć wiele niezarządzanych reprezentacji mapujących się na pojedynczy zarządzany typ lub brakujące informacje o typie, takie jak rozmiar tablicy. W przypadku niejednoznacznych typów marshaller udostępnia domyślną reprezentację i alternatywne reprezentacje, gdzie istnieje wiele reprezentacji. Możesz podać jawne instrukcje do marshallera na temat sposobu marshalingu niejednoznacznego typu.

Wywoływanie platformy i modele międzyoperacyjne COM

Środowisko uruchomieniowe języka wspólnego udostępnia dwa mechanizmy współdziałania z kodem niezarządzanym:

• Wywołanie platformy, które umożliwia kodowi zarządzanemu wywoływanie funkcji wyeksportowanych z niezarządzanej biblioteki.
• Interop COM, który umożliwia interakcję kodu zarządzanego z obiektami COM za pośrednictwem interfejsów.

Zarówno wywołania platform, jak i międzyoperacyjny model COM używają marszalingu międzyoperacyjnego do dokładnego przenoszenia argumentów metod pomiędzy wywołującym a wywoływanym oraz z powrotem, jeśli jest to wymagane. Jak pokazano na poniższej ilustracji, wywołanie metody platformy przepływa z zarządzanego do niezarządzanego kodu i nigdy odwrotnie, z wyjątkiem przypadków, gdy funkcje wywołania zwrotnego są zaangażowane. Mimo że wywołania platformy muszą przepływać tylko z zarządzanego do niezarządzanego kodu, dane mogą przepływać w obu kierunkach jako parametry wejściowe lub wyjściowe. Wywołania metod interop modelu COM mogą przepływać w dowolnym kierunku.

Na najniższym poziomie oba mechanizmy korzystają z tej samej usługi międzyoperacyjnej; jednak niektóre typy danych są obsługiwane wyłącznie przez międzyoperacyjność COM lub wywołania platformy. Aby uzyskać szczegółowe informacje, zobacz Domyślne zachowanie marshallingu.

Apartamenty Marshalling i COM

Interop marshaller przenosi dane między stertą wspólnego środowiska uruchomieniowego języka a niezarządzaną stertą. Marshalling występuje za każdym razem, gdy wywołujący i adresat nie mogą operować na tym samym wystąpieniu danych. Interop marshaller umożliwia, aby wywołujący i odbierający wydawali się operować na tych samych danych, nawet jeśli mają własne kopie danych.

COM ma również narzędzie do marshallowania, które przesyła dane między obiegami COM lub różnymi procesami COM. Podczas wywoływania pomiędzy zarządzanym a niezarządzanym kodem w tym samym apartamencie COM, interoperacyjny marshaller jest jedynym zaangażowanym marshallerem. Podczas wywoływania między kodem zarządzanym a kodem niezarządzanym w innym apartmencie COM lub innym procesie, zaangażowany jest zarówno marshaller międzyoperacyjny, jak i marshaller COM.

Klienci COM i serwery zarządzane

Wyeksportowany serwer zarządzany z biblioteką typów zarejestrowaną przez Regasm.exe (Assembly Registration Tool) ma ThreadingModel wpis rejestru ustawiony na Both. Ta wartość wskazuje, że serwer można aktywować w mieszkaniu jednowątkowym (STA) lub wielowątkowym mieszkaniu (MTA). Obiekt serwera jest tworzony w tym samym mieszkaniu co obiekt wywołujący, jak pokazano w poniższej tabeli:

Ponieważ klient i serwer znajdują się w tym samym mieszkaniu, usługa marszalingu międzyoperacyjnego automatycznie zarządza marszalingiem wszystkich danych. Na poniższej ilustracji przedstawiono międzyoperacyjną usługę marshallingową działającą między zarządzanymi a niezarządzanymi stertami w tym samym apartamencie w stylu COM.

Jeśli planujesz wyeksportować serwer zarządzany, należy pamiętać, że klient COM określa mieszkanie serwera. Serwer zarządzany wywoływany przez klienta COM zainicjowany w usłudze MTA musi zapewnić bezpieczeństwo wątków.

Klienci zarządzani i serwery COM

Ustawieniem domyślnym dla zarządzanych mieszkań klienckich jest MTA; jednak typ aplikacji klienta platformy .NET może zmienić ustawienie domyślne. Na przykład ustawienie mieszkania klienta języka Visual Basic to STA. Możesz użyć właściwości System.STAThreadAttribute, System.MTAThreadAttribute, właściwości Thread.ApartmentState lub właściwości Page.AspCompatMode, aby zbadać i zmienić ustawienie mieszkania zarządzanego klienta.

Autor składnika ustawia koligację wątków serwera COM. W poniższej tabeli przedstawiono kombinacje ustawień mieszkania dla klientów platformy .NET i serwerów COM. Pokazuje również wynikające wymagania dotyczące przetwarzania danych dla kombinacji.

Gdy zarządzany klient i serwer niezarządzany znajdują się w tym samym mieszkaniu, usługa międzyoperacyjna obsługuje wszystkie marshalling danych. Jednak gdy klient i serwer są inicjowane w różnych mieszkaniach, wymagane jest również marshalling COM. Na poniższej ilustracji przedstawiono elementy rozmowy między apartamentami.

W przypadku marshalingu między apartamentami można wykonać następujące czynności:

• Zaakceptuj obciążenie związane z przesyłaniem danych między komponentami, które jest zauważalne tylko wtedy, gdy istnieje wiele wywołań przez granicę. Należy zarejestrować bibliotekę typów składnika COM, aby wywołania pomyślnie przekroczyły granicę mieszkania.

• Zmień główny wątek, ustawiając wątek klienta na STA lub MTA. Jeśli na przykład klient języka C# wywołuje wiele składników STA COM, można uniknąć krzyżowego marshalingu, ustawiając główny wątek na STA.

  Uwaga / Notatka

  Po ustawieniu wątku klienta C# na STA, wywołania do składników MTA COM będą wymagały przekazywania danych między obszarami.

Aby uzyskać instrukcje dotyczące jawnego wybierania modelu mieszkania, zobacz Managed and Unmanaged Threading.

Zarządzanie Zdalnymi Wywołaniami

Podobnie jak w przypadku marszalingu między apartamentami, marszaling COM odbywa się przy każdym wywołaniu między zarządzanym a niezarządzanym kodem, gdy obiekty znajdują się w oddzielnych procesach. Przykład:

• Klient COM, który wywołuje serwer zarządzany na hoście zdalnym, używa rozproszonego modelu COM (DCOM).
• Zarządzany klient, który wywołuje serwer COM na zdalnym hoście, używa DCOM.

Na poniższej ilustracji pokazano, jak interop marshalling i COM marshalling zapewniają kanały komunikacji przez bariery procesów i hostów.

Zachowywanie tożsamości

Common Language Runtime zachowuje tożsamość zarządzanych i niezarządzanych odwołań. Na poniższej ilustracji przedstawiono przepływ bezpośrednich odwołań niezarządzanych (górny wiersz) i bezpośrednich odwołań zarządzanych (dolny wiersz) przez granice procesu i hosta.

Na tej ilustracji:

• Niezarządzany klient pobiera odwołanie do obiektu COM z zarządzanego obiektu, który pobiera to odwołanie z hosta zdalnego. Mechanizm komunikacji zdalnie to DCOM.

• Klient zarządzany pobiera odwołanie do obiektu zarządzanego z obiektu COM, który pobiera to odwołanie z hosta zdalnego. Mechanizm komunikacji zdalnie to DCOM.

  Uwaga / Notatka

  Wyeksportowana biblioteka typów serwera zarządzanego musi być zarejestrowana.

Liczba granic procesów między wywołującym i wywoływanym jest nieistotna; to samo bezpośrednie odwoływanie się występuje w przypadku wywołań wewnątrz procesu i poza procesem.

Komunikacja zdalna zarządzana

Środowisko uruchomieniowe udostępnia również zarządzaną komunikację zdalną, której można użyć do ustanowienia kanału komunikacji między obiektami zarządzanymi przez granice procesów i hostów. Zdalne zarządzanie może obejmować zaporę ogniową między komponentami komunikacyjnymi, jak pokazano na poniższej ilustracji.

Zdalne wywołania między zaporami za pomocą protokołu SOAP lub klasy TcpChannel Zdalne wywołania między zaporami za pomocą protokołu SOAP lub klasy TcpChannel

Niektóre niezarządzane wywołania mogą być przekazywane za pośrednictwem protokołu SOAP, takie jak wywołania między składnikami usługowymi a COM.

Tematy pokrewne

Źródło

System.Runtime.InteropServices