Přehled interoperability spravovaného nebo nespravovaného kódu

Článek
04/30/2007

Sonja Keserovic, programová manažerka
David Mortenson, vedoucí inženýr softwarového designu
Adam Nathan, vedoucí inženýr softwarového návrhu v testech

Microsoft Corporation

Dne

Platí pro:
Microsoft® .NET Framework
Zprostředkovatel komunikace s objekty COM

Shrnutí: Tento článek obsahuje základní informace o interoperabilitě mezi spravovaným a nespravovaným kódem a pokyny a běžné postupy pro přístup a zabalení nespravovaného rozhraní API ze spravovaného kódu a pro vystavení spravovaných rozhraní API nespravovaným volajícím. Jsou také zdůrazněny aspekty zabezpečení a spolehlivosti, údaje o výkonu a obecné postupy pro procesy vývoje. (14 vytištěných stránek)

Požadavky: Cílová skupina tohoto dokumentu zahrnuje vývojáře a manažery, kteří se potřebují na vysoké úrovni rozhodovat o tom, kde se má spravovaný kód používat. K tomu je užitečné pochopit, jak funguje interakce mezi spravovaným a nespravovaným kódem a jak se aktuální pokyny vztahují na konkrétní scénáře.

Obsah

Úvod do interoperability
Pokyny k interoperabilitě
Zabezpečení
Spolehlivost
Výkon
Příloha 1: Překročení hranice interoperability
Příloha 2: Zdroje
Příloha 3: Glosář termínů

Úvod do interoperability

Modul CLR (Common Language Runtime) podporuje interakci spravovaného kódu s komponentami MODELU COM, službami MODELU COM+, rozhraním API Win32® a dalšími typy nespravovaného kódu. Datové typy, mechanismy zpracování chyb, pravidla vytváření a ničení a pokyny k návrhu se liší mezi spravovanými a nespravovanými objektovými modely. Aby se zjednodušila spolupráce mezi spravovaným a nespravovaným kódem a usnadnila se migrace, vrstva pro spolupráci CLR skrývá rozdíly mezi těmito objektovými modely klientů i serverů.

Interoperabilita ("interop") je obousměrná, což umožňuje:

Volání nespravovaných rozhraní API ze spravovaného kódu

To lze provést jak pro plochá rozhraní API (statické exporty knihoven DLL, jako je rozhraní API Win32, které je vystaveno z knihoven DLL, jako jsou kernel32.dll a user32.dll), tak pro rozhraní API modelu COM (objektové modely, jako jsou modely vystavené Microsoftem® Word, Excelem, Internet Explorerem, activeX® data objects (ADO) atd.).
Zveřejnění spravovaných rozhraní API nespravovanému kódu

K tomu patří například vytvoření doplňku pro aplikaci založené na modelu COM, jako je Windows Media® Player, nebo vložení ovládacího prvku spravovaného model Windows Forms do formuláře MFC.

Tyto spravované/nespravované interakce umožňují tři doplňkové technologie:

Volání platformy (někdy označované jako P/Invoke) umožňuje volat libovolnou funkci v libovolném nespravovaném jazyce, pokud je její podpis znovu uveden ve spravovaném zdrojovém kódu. Je to podobné funkcím, které byly poskytnuty příkazem Declare v jazyce Visual Basic® 6.0.
Komunikace modelu COM umožňuje volání komponent modelu COM v libovolném spravovaném jazyce podobným způsobem jako při použití normálních spravovaných komponent a naopak. Komunikace modelu COM se skládá ze základních služeb poskytovaných clr a některých nástrojů a rozhraní API v oboru názvů System.Runtime.InteropServices .
Interop jazyka C++ (někdy označovaný jako It Just Works (IJW)) je funkce specifická pro jazyk C++, která umožňuje přímé použití plochých rozhraní API a rozhraní COM API tak, jak se používala vždy. To je výkonnější než komunikace COM, ale vyžaduje mnohem větší péči. Před použitím této technologie zkontrolujte prostředky jazyka C++.

Pokyny k interoperabilitě

Volání nespravovaných rozhraní API ze spravovaného kódu

Existuje několik typů nespravovaných rozhraní API a několik typů interop technologií, které je možné do nich volat. V této části jsou popsány návrhy, jak a kdy tyto technologie používat. Upozorňujeme, že tyto návrhy jsou velmi obecné a nepokrývají všechny scénáře. Měli byste pečlivě vyhodnotit své scénáře a použít vývojové postupy nebo řešení, která jsou pro váš scénář vhodná.

Volání nespravovaných plochých rozhraní API

Existují dva mechanismy volání do nespravovaných plochých rozhraní API ze spravovaného kódu: prostřednictvím volání platformy (k dispozici ve všech spravovaných jazycích) nebo prostřednictvím zprostředkovatele C++ (k dispozici v C++).

Než se rozhodnete volat ploché rozhraní API pomocí některé z těchto technologií spolupráce, měli byste zjistit, zda je v rozhraní .NET Framework k dispozici ekvivalentní funkce. Pokud je to možné, doporučujeme místo volání nespravovaných rozhraní API používat funkce rozhraní .NET Framework.

Pro volání jen několika nespravovaných metod nebo pro volání jednoduchých plochých rozhraní API je návrh použít volání platformy místo zprostředkovatele komunikace C++. Psaní deklarací volání platformy pro jednoduchá plochá rozhraní API je jednoduché. ClR se postará o načítání knihovny DLL a zařazování všech parametrů. Dokonce i práce na vytvoření několika deklarací volání platformy pro složitá plochá rozhraní API je zanedbatelná ve srovnání s náklady na používání zprostředkovatele C++ a zavedení zcela nového modulu napsaného v jazyce C++.

Pro zabalení složitých nespravovaných plochých rozhraní API nebo zabalení nespravovaných plochých rozhraní API, která se mění v době vývoje spravovaného kódu, doporučujeme místo volání platformy použít interop jazyka C++. Vrstva C++ může být velmi tenká a zbytek spravovaného kódu může být napsán v libovolném jiném spravovaném jazyce. Použití volání platformy v těchto scénářích by vyžadovalo velké úsilí k opětovné deklaraci složitých částí rozhraní API ve spravovaném kódu a jejich synchronizaci s nespravovanými rozhraními API. Použití zprostředkovatele Zprostředkovatele C++ tento problém řeší povolením přímého přístupu k nespravovaným rozhraním API – což nevyžaduje přepisování, pouze zahrnutí souboru hlaviček.

Volání rozhraní API modelu COM

Existují dva způsoby volání komponent modelu COM ze spravovaného kódu: prostřednictvím zprostředkovatele com (k dispozici ve všech spravovaných jazycích) nebo prostřednictvím zprostředkovatele C++ (k dispozici v C++).

Pro volání komponent MODELU COM kompatibilních se službou OLE Automation se navrhuje použít zprostředkovatele zprostředkovatele COM. ClR se postará o aktivaci komponent modelu COM a zařazování parametrů.

Pro volání komponent modelu COM založených na jazyce IDL (Interface Definition Language) doporučujeme použít zprostředkovatele komunikace C++. Vrstva C++ může být velmi tenká a zbytek spravovaného kódu může být napsán v libovolném spravovaném jazyce. Komunikace modelu COM se při provádění správných volání zprostředkovatele komunikace spoléhá na informace z knihoven typů, ale knihovny typů obvykle neobsahují všechny informace, které jsou přítomné v souborech IDL. Použití zprostředkovatele komunikace C++ tento problém vyřeší povolením přímého přístupu k těmto rozhraním COM API.

Pro společnosti, které vlastní rozhraní API modelu COM, která již byla dodána, je důležité zvážit odeslání primárních sestavení zprostředkovatelských služeb (PIA) pro tato rozhraní API, aby je bylo možné snadno využívat pro spravované klienty.

Rozhodovací strom pro volání nespravovaných rozhraní API

Obrázek 1: Rozhodovací strom volání nespravovaných rozhraní API

Vystavení spravovaných rozhraní API nespravovanému kódu

Existují dva hlavní způsoby, jak zpřístupnit spravované rozhraní API čistě nespravovaným volajícím: jako rozhraní COM API nebo jako ploché rozhraní API. Pro nespravované klienty C++, kteří jsou ochotni znovu zkompilovat svůj kód pomocí sady Visual Studio® .NET, existuje třetí možnost: přímý přístup ke spravovaným funkcím prostřednictvím zprostředkovatele komunikace jazyka C++. V této části jsou popsány návrhy, jak a kdy tyto možnosti použít.

Přímý přístup ke spravovanému rozhraní API

Pokud je nespravovaný klient napsaný v jazyce C++, lze ho zkompilovat pomocí kompilátoru jazyka C++ sady Visual Studio .NET jako "image smíšeného režimu". Po dokončení bude mít nespravovaný klient přímý přístup k libovolnému spravovanému rozhraní API. Některá pravidla kódování se však vztahují na přístup ke spravovaným objektům z nespravovaného kódu; Další podrobnosti najdete v dokumentaci k jazyku C++.

Upřednostňovanou možností je přímý přístup, protože nevyžaduje zvláštní pozornost vývojářů spravovaných rozhraní API. Můžou navrhnout své spravované rozhraní API podle pokynů pro návrh spravovaného rozhraní API (DG) a mít jistotu, že rozhraní API bude stále přístupné nespravovaným volajícím.

Zveřejnění spravovaného rozhraní API jako rozhraní COM API

Každou veřejně spravovanou třídu je možné zpřístupnit nespravovaným klientům prostřednictvím komunikace MODELU COM. Tento proces se velmi snadno implementuje, protože vrstva zprostředkovatele COM se postará o všechny instalatérské práce modelu COM. Proto se například zdá, že každá spravovaná třída implementuje IUnknown, IDispatch, ISupportErrorInfo a několik dalších standardních rozhraní COM.

Navzdory skutečnosti, že zveřejnění spravovaných rozhraní API jako rozhraní COM API je snadné, spravované a objektové modely modelu COM se velmi liší. Proto by zveřejnění spravovaného rozhraní API pro com mělo být vždy explicitním rozhodnutím o návrhu. Některé funkce dostupné ve spravovaném světě nemají ve světě modelu COM žádný ekvivalent a nebudou použitelné z klientů MODELU COM. Z tohoto důvodu často dochází k napětí mezi pokyny pro návrh spravovaného rozhraní API (DG) a kompatibilitou s modelem COM.

Pokud jsou klienti COM důležití, napište spravované rozhraní API podle pokynů pro návrh spravovaného rozhraní API a pak kolem spravovaného rozhraní API, který bude vystaven modelu COM, napište tenkou spravovanou obálku, která je vhodná pro com.

Zveřejnění spravovaného rozhraní API jako plochého rozhraní API

Někdy nespravované klienty nelze použít com. Například už můžou být napsané tak, aby používaly plochá rozhraní API, a nelze je změnit ani znovu zkompilovat. C++ je jediný jazyk vysoké úrovně, který umožňuje zveřejnit spravovaná rozhraní API jako plochá rozhraní API. Není to tak jednoduché jako zveřejnění spravovaného rozhraní API jako rozhraní COM API. Jedná se o velmi pokročilou techniku, která vyžaduje pokročilé znalosti spolupráce C++ a rozdílů mezi spravovaným a nespravovaným světem.

Vystavte své spravované rozhraní API jako ploché rozhraní API pouze v případě, že je to nezbytně nutné. Pokud nemáte na výběr, nezapomeňte si projít dokumentaci jazyka C++ a být si plně vědomi všech omezení.

Rozhodovací strom pro zveřejnění spravovaných rozhraní API

Obrázek 2. Zveřejnění rozhodovacího stromu spravovaných rozhraní API

Zabezpečení

Modul CLR (Common Language Runtime) se dodává se systémem zabezpečení přístupu kódu (CAS), který reguluje přístup k chráněným prostředkům na základě informací o původu sestavení. Volání nespravovaného kódu představuje velké bezpečnostní riziko. Bez odpovídajících kontrol zabezpečení by nespravovaný kód mohl manipulovat s jakýmkoli stavem jakékoli spravované aplikace v procesu CLR. Prostředky v nespravovaném kódu je také možné volat přímo, aniž by tyto prostředky podléhaly kontrolám oprávnění CAS. Z tohoto důvodu se každý přechod na nespravovaný kód považuje za vysoce chráněnou operaci a měla by zahrnovat kontrolu zabezpečení. Tato kontrola zabezpečení hledá oprávnění nespravovaného kódu, které vyžaduje, aby sestavení obsahující nespravovaný přechod kódu a všechna sestavení, která do něj volala, měla právo skutečně vyvolat nespravovaný kód.

Existují některé omezené scénáře interoperability, kdy jsou úplné kontroly zabezpečení zbytečné a nadměrně by omezovaly výkon nebo rozsah komponenty. Jedná se o případ, kdy prostředek vystavený nespravovaným kódem nemá žádný význam pro zabezpečení (systémový čas, souřadnice okna atd.) nebo pokud se prostředek používá pouze interně v sestavení a není veřejně zpřístupněn libovolným volajícím. V takových případech můžete u všech volajících příslušných rozhraní API potlačit úplnou kontrolu zabezpečení pro nespravovaný kód. Provedete to použitím vlastního atributu SuppressUnmanagedCodeSecurity na příslušnou metodu nebo třídu zprostředkovatele komunikace. Upozorňujeme, že se předpokládá pečlivá kontrola zabezpečení, pokud jste zjistili, že taková rozhraní API by nemohl zneužít žádný částečně důvěryhodný kód.

Spolehlivost

Spravovaný kód je navržený tak, aby byl spolehlivější a robustnější než nespravovaný kód. Jedním z příkladů funkce CLR, která tyto vlastnosti podporuje, je uvolňování paměti, které se postará o uvolnění nepoužívané paměti, aby se zabránilo nevracení paměti. Dalším příkladem je zabezpečení spravovaných typů, které se používá k zabránění chybám přetečení vyrovnávací paměti a dalším chybám souvisejícím s typem.

Pokud používáte jakýkoli typ technologie interoperability, váš kód nemusí být tak spolehlivý nebo robustní jako čistě spravovaný kód. Například můžete potřebovat přidělit nespravovanou paměť ručně a nezapomeňte ji uvolnit, až s ní skončíte.

Psaní jakéhokoli netriviálního kódu zprostředkovatele komunikace vyžaduje stejnou pozornost spolehlivosti a odolnosti jako psaní nespravovaného kódu. I když je veškerý kód zprostředkovatele komunikace napsaný správně, bude váš systém spolehlivý jen tak jako jeho nespravované části.

Výkon

Při každém přechodu ze spravovaného kódu na nespravovaný kód (a naopak) existuje určitá režie na výkon. Výše režie závisí na typech použitých parametrů. Vrstva zprostředkovatele komunikace CLR používá tři úrovně optimalizace volání zprostředkovatele komunikace na základě typu přechodu a typů parametrů: vkládání za běhu (JIT), kompilované zástupné procedury sestavení a interpretované zástupné procedury zařazování (v pořadí nejrychlejšího až nejpomalejšího typu volání).

Přibližná režie volání volání platformy: 10 instrukcí počítače (na procesoru x86)

Přibližná režie při volání zprostředkovatele komunikace COM: 50 pokynů pro počítač (na procesoru x86)

Práce provedené podle těchto pokynů je uvedena v částech příloha Volání plochého rozhraní API: Krok za krokem a Volání rozhraní API modelu COM: Krok za krokem. Kromě zajištění, že systém uvolňování paměti nebude blokovat nespravovaná vlákna během volání, a zpracování konvencí volání a nespravovaných výjimek, com interop dělá další práci při převodu volání aktuálního modulu runtime volatelné obálky (RCW) na ukazatel rozhraní COM odpovídající aktuálnímu kontextu.

Každé volání zprostředkovatele komunikace přináší určitou režii. V závislosti na tom, jak často k těmto voláním dochází, a významu práce probíhající uvnitř implementace metody může režijní náklady na volání sahat od zanedbatelných po velmi znatelné.

Na základě těchto důležitých informací najdete v následujícím seznamu některé obecné návrhy výkonu, které by pro vás mohly být užitečné:

Pokud řídíte rozhraní mezi spravovaným a nespravovaným kódem, nastavte ho na "chunky" místo "chatrného", abyste snížili celkový počet provedených přechodů.

Chatty rozhraní jsou rozhraní, která provádějí velké množství přechodů, aniž by prováděla žádnou významnou práci na druhé straně hranice interoperability. Například vlastnosti setter a getters jsou chatty. Chunky rozhraní jsou rozhraní, která provádějí pouze několik přechodů, a množství práce provedené na druhé straně hranice je významné. Například metoda, která otevře připojení k databázi a načte některá data, je chunká. Chunky rozhraní zahrnují méně přechodů zprostředkovatele komunikace, takže eliminujete některé režijní náklady na výkon.
Pokud je to možné, vyhněte se převodům unicode a ANSI.

Převod řetězců z Unicode na ANSI a naopak je nákladná operace. Například pokud je třeba předat řetězce, ale jejich obsah není důležitý, můžete deklarovat parametr řetězce jako IntPtr a zařazovač interoperability nebude provádět žádné převody.
Ve scénářích s vysokým výkonem může deklarování parametrů a polí jako IntPtr zvýšit výkon, i když na úkor snadného použití a udržovatelnosti.

Někdy je rychlejší provést ruční zařazování pomocí metod dostupných ve třídě Marshal , než spoléhat na výchozí zařazování zprostředkovatele komunikace. Například pokud velké pole řetězců musí být předány přes hranici interoperability, ale bude potřeba pouze několik prvků, deklarování pole jako IntPtr a přístup pouze k těmto několika prvkům ručně bude mnohem rychlejší.
Používejte inAttribute a OutAttribute moudře, abyste omezili zbytečné zařazování.

Zařazovač zprostředkovatele komunikace používá výchozí pravidla při rozhodování, jestli je třeba určitý parametr zařadit před voláním a zařadí se ven po volání. Tato pravidla jsou založená na úrovni indirecte a typu parametru. Některé z těchto operací nemusí být nutné v závislosti na sémantice metody.
Pro vyvolání podpisů platformy použijte SetLastError=false jenom v případě, že budete později volat Marshal.GetLastWin32Error .

Nastavení SetLastError=true u podpisů volání platformy vyžaduje další práci z vrstvy zprostředkovatele komunikace, aby se zachoval poslední kód chyby. Tuto funkci používejte jenom v případě, že se na tyto informace spoléháte a budete je používat po volání.
Pokud a pouze v případě, nespravované volání jsou zpřístupněny způsobem, který není zneužitelný, použijte SuppressUnmanagedCodeSecurityAttribute snížit počet kontrol zabezpečení.

Kontroly zabezpečení jsou velmi důležité. Pokud vaše rozhraní API nezveřejňuje žádné chráněné prostředky nebo citlivé informace nebo jsou dobře chráněné, mohou rozsáhlé kontroly zabezpečení představovat zbytečné režijní náklady. Náklady na to, že neprovádíte žádnou kontrolu zabezpečení, jsou ale velmi vysoké.

Příloha 1: Překročení hranice interoperability

Volání plochého rozhraní API: Krok za krokem

Obrázek 3: Volání plochého rozhraní API

Získejte LoadLibrary a GetProcAddress.
Vytvořte zástupný soubor DllImport z podpisu obsahujícího cílovou adresu.
Nasdílení volaných uložených registrů
Nastavte rámeček DllImport a vložte ho do zásobníku rámců.
Pokud je přidělena dočasná paměť, inicializujte seznam čištění pro rychlé uvolnění po dokončení volání.
Zařazování parametrů. (To by mohlo přidělit paměť.)
Změňte režim uvolňování paměti z kooperativního na preemptivní, aby k uvolňování paměti mohlo dojít kdykoli.
Načtěte cílovou adresu a zavolejte ji.
Pokud je nastaven bit SetLastError , zavolejte Metodu GetLastError a uložte výsledek do abstrakce vlákna uložené v místním úložišti vlákna.
Změňte zpět na kooperativní režim uvolňování paměti.
Pokud PreserveSig=false a metoda vrátila chybu HRESULT, vyvolá výjimku.
Pokud se nevyvolá žádná výjimka, vymažete zpět parametry a parametry by-ref.
Obnovte rozšířený ukazatel zásobníku na jeho původní hodnotu, aby se zohlednily argumenty s voláním.

Volání rozhraní COM API: Krok za krokem

Obrázek 4. Volání rozhraní COM API

Z podpisu sestavte zástupný znak spravované na nespravovanou proceduru.
Nasdílení volaných uložených registrů
Nastavte rámec komunikace modelu COM se spravovaným až nespravovaným objektem a nasdílete ho do zásobníku rámců.
Zarezervujte místo pro dočasná data použitá během přechodu.
Pokud je přidělena dočasná paměť, inicializujte seznam čištění pro rychlé uvolnění po dokončení volání.
Vymažte příznaky výjimek s plovoucí desetinou čárkou (pouze x86).
Zařazování parametrů. (To by mohlo přidělit paměť.)
Načte správný ukazatel rozhraní pro aktuální kontext uvnitř obálky volatelné za běhu. Pokud nelze použít ukazatel v mezipaměti, volání QueryInterface na com komponentu získat.
Změňte režim uvolňování paměti z kooperativního na preemptivní, aby k uvolňování paměti mohlo dojít kdykoli.
Z ukazatele vtable indexujte podle čísla slotu, získejte cílovou adresu a zavolejte ji.
Volejte Release na ukazatel rozhraní, pokud byl dříve volána QueryInterface .
Změňte zpět na kooperativní režim uvolňování paměti.
Pokud podpis není označený PreserveSig, zkontrolujte, jestli nedošlo k chybě HRESULT, a vyvolte výjimku (potenciálně vyplněné informacemi O chybě IErrorInfo ).
Pokud se nevyvolá žádná výjimka, vymažete zpět parametry a parametry by-ref.
Obnovte rozšířený ukazatel zásobníku na původní hodnotu, aby se zohlednily argumenty s voláním.

Volání spravovaného rozhraní API z modelu COM: Krok za krokem

Obrázek 5. Volání spravovaného rozhraní API z modelu COM

Vytvořte z podpisu nespravovanou proceduru se správou.
Nasdílení volaných uložených registrů
Nastavte nespravovaný rámec zprostředkovatele komunikace com a nasdílíte ho do zásobníku rámců.
Zarezervujte místo pro dočasná data použitá během přechodu.
Změňte režim uvolňování paměti ze spolupráce na preemptivní, aby k uvolňování paměti mohlo dojít kdykoli.
Načtěte obálku volatelného modelu COM (CCW) z ukazatele rozhraní.
Načtěte spravovaný objekt uvnitř CCW.
Přechod aplikačních domén v případě potřeby
Pokud je doména aplikace bez plné důvěryhodnosti, proveďte všechny požadavky na propojení, které může metoda mít s cílovou doménou appdomain.
Pokud je přidělena dočasná paměť, inicializujte seznam čištění, aby se po dokončení volání rychle uvolnilo.
Zařazování parametrů. (To by mohlo přidělit paměť.)
Vyhledejte metodu spravovanou cílem, která se má volat. (To zahrnuje mapování volání rozhraní na cílovou implementaci.)
Návratová hodnota se ukládá do mezipaměti. (Pokud se jedná o návratovou hodnotu s plovoucí desetinou čárkou, získejte ji z registru s plovoucí desetinou čárkou.)
Změňte zpět na kooperativní režim uvolňování paměti.
Pokud došlo k výjimce, extrahujte jeho HRESULT, aby se vrátil, a zavolejte SetErrorInfo.
Pokud nedošlo k žádné výjimce, parametry back-propagat out a by-ref .
Obnovte rozšířený ukazatel zásobníku na původní hodnotu, aby se zohlednily argumenty volajícího.

Příloha 2: Zdroje

Musí číst!.NET a COM: The Complete Interoperability Guide by Adam Nathan

Spolupráce s nespravovaným kódem, Příručka pro vývojáře rozhraní Microsoft .NET Framework

Ukázky zprostředkovatele, Microsoft .NET Framework

Blog uživatele Adam Nathan

Blog uživatele Chris Brumme

Příloha 3: Glosář termínů

AppDomain (doména aplikace)	Doménu aplikace lze považovat za podobnou jednoduchému procesu operačního systému a je spravována modulem CLR (Common Language Runtime).
CCW (volatelný obálka COM)	Speciální druh obálky vytvořené vrstvou zprostředkovatele komunikace CLR kolem spravovaných objektů aktivovaných z kódu COM. CCW skrývá rozdíly mezi spravovanými objektovými modely a objektovými modely MODELU COM tím, že poskytuje zařazování dat, správu životnosti, správu identit, zpracování chyb, správné přechody apartmentů a vláken atd. CcWs zpřístupňují funkce spravovaných objektů způsobem, který je přátelský k modelu COM, aniž by implementátor spravovaného kódu musel něco vědět o instalatérství modelu COM.
CLR	Common Language Runtime.
zprostředkovatel komunikace s objekty COM	Služba poskytovaná vrstvou zprostředkovatele komunikace CLR pro použití rozhraní COM API ze spravovaného kódu nebo vystavení spravovaných rozhraní API jako rozhraní COM API nespravovaným klientům. Komunikace modelu COM je dostupná ve všech spravovaných jazycích.
Spolupráce jazyka C++	Služba poskytovaná kompilátorem jazyka C++ a CLR se používá k přímému kombinování spravovaného a nespravovaného kódu ve stejném spustitelném souboru. Spolupráce jazyka C++ obvykle zahrnuje zahrnutí souborů hlaviček do nespravovaných rozhraní API a dodržování určitých pravidel kódování.
Komplexní ploché rozhraní API	Rozhraní API s podpisy, které je obtížné deklarovat ve spravovaném jazyce. Například metody s parametry struktury proměnné velikosti je obtížné deklarovat, protože ve spravovaném systému typů neexistuje žádný ekvivalentní koncept.
Zprostředkovatel komunikace	Obecný termín, který zahrnuje jakýkoli typ interoperability mezi spravovaným a nespravovaným kódem (označovaným také jako nativní). Interop je jednou z mnoha služeb poskytovaných CLR.
Sestavení zprostředkovatele komunikace	Speciální typ spravovaného sestavení, které obsahuje ekvivalenty spravovaného typu pro typy modelu COM obsažené v knihovně typů. Obvykle se vytváří spuštěním nástroje Type Library Importer (Tlbimp.exe) v knihovně typů.
Spravovaný kód	Kód spouštěný pod kontrolou modulu CLR se nazývá spravovaný kód. Například jakýkoli kód napsaný v jazyce C# nebo Visual Basic .NET je spravovaný kód.
Volání platformy	Služba poskytovaná vrstvou zprostředkovatele komunikace CLR pro volání nespravovaných plochých rozhraní API ze spravovaného kódu. Volání platformy je k dispozici ve všech spravovaných jazycích.
RCW (volatelný wapper modulu runtime)	Speciální druh obálky vytvořené vrstvou zprostředkovatele clr kolem objektů COM, které jsou aktivovány ze spravovaného kódu. RcW skrývá rozdíly mezi spravovanými objektovými modely a objektovými modely MODELU COM tím, že poskytuje zařazování dat, správu životnosti, správu identit, zpracování chyb, správné přechody objektů typu apartment a threading atd.
Nespravovaný kód	Kód, který běží mimo CLR, se označuje jako "nespravovaný kód". Příklady nespravovaného kódu jsou komponenty MODELU COM, komponenty ActiveX a funkce rozhraní API Win32.

Share via