Dela via

COM-wrapperkomponenter

COM skiljer sig från .NET-körningsobjektmodellen på flera viktiga sätt:

  • Klienter för COM-objekt måste hantera livslängden för dessa objekt. den vanliga språkkörningen hanterar livslängden för objekt i dess miljö.

  • Klienter för COM-objekt upptäcker om en tjänst är tillgänglig genom att begära ett gränssnitt som tillhandahåller den tjänsten och få tillbaka en gränssnittspekare eller inte. Klienter för .NET-objekt kan få en beskrivning av ett objekts funktioner med reflektion.

  • .NET-objekt finns i minnet som hanteras av körningsmiljön för .NET-runtime. Körningsmiljön kan flytta runt objekt i minnet av prestandaskäl och uppdatera alla referenser till de objekt som flyttas. Ohanterade klienter, som har fått en pekare till ett objekt, förlitar sig på att objektet ska finnas kvar på samma plats. Dessa klienter har ingen mekanism för att hantera ett objekt vars plats inte är fast.

För att överkomma dessa skillnader tillhandahåller körtiden omslutningsklasser för att få både hanterade och ohanterade klienter att tro att de anropar objekt inom sina respektive miljöer. När din hanterade klient anropar en metod på ett COM-objekt skapar körningen en runtime-anropsbar omslutning (RCW). RCWs abstraherar skillnaderna mellan hanterade och ohanterade referensmekanismer, bland annat. Körtiden skapar också en COM-anropsbar omslutning (CCW) för att vända processen, vilket gör det möjligt för en COM-klient att sömlöst anropa en metod på ett .NET-objekt. Som följande bild visar avgör perspektivet för den anropande koden vilken omslutningsklass som körningen skapar.

Översikt över COM-omslutning

I de flesta fall tillhandahåller standard-RCW eller CCW som genereras av programkörningen lämplig marshalling för anrop som korsar gränsen mellan COM och .NET-programkörningen. Med anpassade attribut kan du valfritt justera hur körtiden representerar hanterad och ohanterad kod.

Se även