Organizowanie międzyoperacyjne

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 w czasie wykonywania 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 zawierać wiele niezarządzanych reprezentacji, które są mapowane na pojedynczy typ zarządzany lub brakujące informacje o typie, takie jak rozmiar tablicy. W przypadku niejednoznacznych typów marshaller udostępnia domyślną reprezentację i alternatywne reprezentacje, w których istnieje wiele reprezentacji. Możesz podać jawne instrukcje do marshallera na temat sposobu marshalingu niejednoznacznego typu.

Wywoływanie platformy i modele międzyoperacowe MODELU MODELU 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.
• Międzyoperacyjności modelu COM, który umożliwia interakcję kodu zarządzanego z obiektami modelu obiektów składników (COM) za pośrednictwem interfejsów.

Zarówno wywołanie platformy, jak i międzyoperacyjność modelu COM używają międzyoperacyjności do dokładnego przenoszenia argumentów metody między obiektami wywołującymi i wywoływanymi i wstecznymi, jeśli jest to wymagane. Jak pokazano na poniższej ilustracji, platforma wywołuje przepływy wywołania metody z zarządzanego do niezarządzanego kodu i nigdy w inny sposób, z wyjątkiem sytuacji, gdy są zaangażowane funkcje wywołania zwrotnego. Mimo że wywołania wywołań platformy mogą 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 metody międzyoperacyjnej modelu COM mogą przepływać w obu kierunkach.

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ędzyoperajności modelu COM lub wywołania platformy. Aby uzyskać szczegółowe informacje, zobacz Domyślne zachowanie marshallingu.

Apartamenty Marshalling i COM

Interop marshaller marshalsuje dane między stertą środowiska uruchomieniowego języka wspólnego a niezarządzanym stertą. Marshalling występuje za każdym razem, gdy obiekt wywołujący i wywoływany nie może działać na tym samym wystąpieniu danych. Interop marshaller umożliwia wywoływanie i wywoływanie wydaje się działać na tych samych danych, nawet jeśli mają własną kopię danych.

COM ma również marshaller, który marshaluje dane między mieszkaniami COM lub różnymi procesami COM. Podczas wywoływania między zarządzanym i niezarządzanym kodem w tym samym mieszkaniu COM, międzyoperator jest jedynym marshallerem zaangażowanym. Podczas wywoływania między kodem zarządzanym a niezarządzanym kodem w innym mieszkaniu COM lub innym procesie zaangażowany jest zarówno międzyoperator, jak i marshaller COM.

Klienci MODELU COM i serwery zarządzane

Wyeksportowany serwer zarządzany z biblioteką typów zarejestrowaną przez Regasm.exe (narzędzie rejestracji zestawów) ma ThreadingModel wpis rejestru ustawiony na Bothwartość . 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:

Klient COM	Serwer .NET	Wymagania dotyczące marshallingu
STA	Both staje się STA.	Marshalling tego samego mieszkania.
MTA	Both staje się MTA.	Marshalling tego samego mieszkania.

Ponieważ klient i serwer znajdują się w tym samym mieszkaniu, usługa międzyoperacyjnej automatycznie obsługuje wszystkie marshalling danych. Na poniższej ilustracji przedstawiono międzyoperajną usługę marshallingową działającą między zarządzanymi i niezarządzanych stertami w tym samym mieszkaniu 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ć System.STAThreadAttributewłaściwości , , System.MTAThreadAttributeThread.ApartmentState lub Page.AspCompatMode właściwości , 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ż wynikowe wymagania dotyczące marshallingu dla kombinacji.

Klient .NET	Serwer COM	Wymagania dotyczące marshallingu
MTA (ustawienie domyślne)	MTA STA	Interop marshalling. Interop i COM marshalling.
STA	MTA STA	Interop i COM marshalling. Interop marshalling.

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 wywołania między apartamentami:

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

• Zaakceptuj obciążenie przekreśliwające między mieszkaniami, które jest zauważalne tylko wtedy, gdy istnieje wiele połączeń 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

  Po ustawieniu wątku klienta języka C# na STA wywołania składników MTA COM będą wymagały krzyżowego marshalingu.

Aby uzyskać instrukcje dotyczące jawnego wybierania modelu mieszkania, zobacz Managed and Unmanaged Threading (Zarządzanie i niezarządzane wątkowanie).

Marshaling Remote Calls

Podobnie jak w przypadku marshalingu między apartamentami, marshalling COM jest zaangażowany w każde wywołanie między zarządzanym i niezarządzanym kodem za każdym razem, gdy obiekty znajdują się w oddzielnych procesach. Na 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 hoście zdalnym, używa modelu DCOM.

Na poniższej ilustracji pokazano, jak międzyoperacyjne i com marshalling zapewniają kanały komunikacji między granicami procesów i hostów:

Zachowywanie tożsamości

Środowisko uruchomieniowe języka wspólnego 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 (dolnego wiersza) między granicami 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

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

Liczba granic procesów między obiektem wywołującym i wywoływanym jest nieistotna; to samo bezpośrednie odwoływanie się występuje w przypadku wywołań w trakcie 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. Komunikacja zdalna zarządzana może pomieścić zaporę między składnikami komunikacji, jak pokazano na poniższej ilustracji:

Zdalne wywołania między zaporami przy użyciu 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ługi i com.

Tematy pokrewne

Nazwa	opis
Domyślne zachowanie marshallingu	Opisuje reguły używane przez usługę pośrednicą do marshalingu danych.
Marshalling Data with Platform Invoke	Opisuje sposób deklarowania parametrów metody i przekazywania argumentów do funkcji eksportowanych przez biblioteki niezarządzane.
Marshalling Data with COM Interop	Opisuje sposób dostosowywania otoek COM w celu zmiany zachowania marshallingu.
Instrukcje: Migrowanie zarządzanego kodu DCOM do WCF	Opisuje sposób migracji z modelu DCOM do programu WCF.
Instrukcje: Mapowanie wyników HRESULT i wyjątków	Opisuje sposób mapowania niestandardowych wyjątków na wartości HRESULTs i zapewnia pełne mapowanie z każdego HRESULT na porównywalną klasę wyjątków w programie .NET Framework.
Współdziałanie przy użyciu typów ogólnych	Opisuje akcje obsługiwane w przypadku korzystania z typów ogólnych na potrzeby współdziałania modelu COM.
Współdziałanie z kodem niezarządzanym	Opisuje usługi współdziałania udostępniane przez środowisko uruchomieniowe języka wspólnego.
Zaawansowane współdziałanie modelu COM	Zawiera linki do dodatkowych informacji na temat dołączania składników COM do aplikacji .NET Framework.
Zagadnienia dotyczące projektowania dotyczące współdziałania	Zawiera porady dotyczące pisania zintegrowanych składników COM.

Odwołanie

System.Runtime.InteropServices