Übersicht über das Interop-Marshalling
Aktualisiert: November 2007
Die meisten Datentypen verfügen über gemeinsame Darstellungen im verwalteten und im nicht verwalteten Speicher. Diese Datentypen werden durch den Interop-Marshaller für Sie behandelt. Andere Typen sind entweder nicht eindeutig oder im verwalteten Speicher gar nicht dargestellt.
Für einen nicht eindeutigen Typ können entweder mehrere nicht verwaltete Darstellungen bestehen, die einem einzelnen verwalteten Typ zugeordnet werden können, oder es fehlen Typinformationen, wie die Größe eines Arrays. Mehrdeutigen Typen stellt der Marshaller eine Standarddarstellung und, wenn mehrere Darstellungen vorhanden sind, alternative Darstellungen zur Verfügung. Sie können dem Marshaller explizite Anweisungen dazu geben, wie mehrdeutige Typen zu marshallen sind.
Am Anfang dieses Themas erhalten Sie eine Übersicht über das Plattformaufruf- und das COM-Interop-Programmiermodell. Im untergeordneten Thema Marshalling und COM-Apartments wird beschrieben, wie das Interop-Marshalling in das COM-Marshalling integriert werden kann. Anschließend wird im untergeordneten Thema Marshalling für Remoteaufrufe beschrieben, wie der Marshaller in einer verteilten Umgebung ausgeführt wird.
Plattformaufruf- und COM-Interop-Modell
Die Common Language Runtime stellt für die Interoperation mit nicht verwaltetem Code zwei Mechanismen zur Verfügung:
Plattformaufruf: Ermöglicht es verwaltetem Code, Funktionen aufzurufen, die aus einer nicht verwalteten Bibliothek exportiert wurden.
COM-Interop: Ermöglicht es verwaltetem Code, über Schnittstellen mit COM-Objekten zusammenzuwirken.
Sowohl Plattformaufruf als auch COM-Interop verwenden zum exakten Verschieben von Methodenargumenten zwischen Aufrufer und Aufgerufenem und (gegebenenfalls) umgekehrt Interop-Marshalling. Wie die folgende Abbildung veranschaulicht, fließt ein Methodenaufruf zum Plattformaufruf immer vom verwalteten zum nicht verwalteten Code, und niemals umgekehrt. Die einzige Ausnahme bilden Situationen, in denen Rückruffunktionen beteiligt sind. Im Gegensatz zu den Aufrufen, die beim Plattformaufruf nur vom verwalteten zum nicht verwalteten Code fließen, können Daten als In- oder Out-Parameter in beide Richtungen fließen. In COM-Interop können Methodenaufrufe in beide Richtungen fließen.
Plattformaufruf- und COM-Interop-Aufruffluss
.gif)
Auf der niedrigsten Ebene verwenden beide Mechanismen denselben Interop-Marshallingdienst; bestimmte Datentypen werden jedoch ausschließlich durch COM-Interop oder Plattformaufruf unterstützt. Ausführliche Informationen finden Sie unter Standardmäßiges Marshallingverhalten.
Marshalling und COM-Apartments
Der Interop-Marshaller marshallt Daten zwischen dem Common Language Runtime-Heap und dem nicht verwalteten Heap. Das Marshalling findet statt, wenn der Aufrufer und der Aufgerufene nicht an derselben Dateninstanz operieren können. Der Interop-Marshaller ermöglicht es dem Aufrufer und dem Aufgerufenen, scheinbar dieselben Daten zu bearbeiten, obwohl Aufrufer und Aufgerufene tatsächlich jeweils mit einer eigenen Kopie der Daten arbeiten.
COM verfügt außerdem über einen Marshaller, der Daten zwischen COM-Apartments oder unterschiedlichen COM-Prozessen marshallt. Bei Aufrufen zwischen verwaltetem und nicht verwaltetem Code innerhalb eines COM-Apartments wird nur der Interop-Marshaller eingesetzt. Bei Aufrufen zwischen verwaltetem und nicht verwaltetem Code in unterschiedlichen COM-Apartments oder Prozessen, werden sowohl der Interop-Marshaller als auch COM-Marshaller eingesetzt.
COM-Client und .NET Server
Bei exportierten verwalteten Servern mit einer durch das Assembly Registration-Tool (Regasm.exe) registrierten Typbibliothek lautet der ThreadingModel-Registrierungseintrag Both. Dieser Wert zeigt an, dass der Server in einem Singlethread-Apartment (STA) oder einem Multithread-Apartment (MTA) aktiviert werden kann. Das Serverobjekt wird in demselben Apartment erstellt wie sein Aufrufer. Siehe folgende Tabelle:
COM-Client |
.NET-Server |
Anforderungen für das Marshalling |
|---|---|---|
STA |
Both wird zu STA. |
Marshalling innerhalb eines Apartments. |
MTA |
Both wird zu MTA. |
Marshalling innerhalb eines Apartments. |
Da Client und Server sich in demselben Apartment befinden, werden die Daten durch den Interop-Marshallingdienst automatisch gemarshallt. In der folgenden Abbildung ist der Interop-Marshallingdienst zwischen verwalteten und nicht verwalteten Heaps eines COM-Apartments dargestellt.
Marshalling innerhalb eines Apartments
.gif)
Wenn ein verwalteter Server exportiert werden soll, muss beachtet werden, dass das Apartment des Servers durch den COM-Client bestimmt wird. Verwaltete Server, die durch in einem MTA initialisierte COM-Clients aufgerufen werden, müssen Threadsicherheit garantieren.
.NET-Client und COM-Server
Die Standardeinstellung für .NET-Clientapartments lautet MTA. Diese Standardeinstellung kann jedoch durch den Anwendungstyp des .NET-Client geändert werden. Eine Clientapartmenteinstellung Visual Basic 2005 ist beispielsweise STA. Um die Apartmenteinstellung für einen verwalteten Client zu überprüfen oder zu ändern, können Sie die STAThreadAttribute-Eigenschaft, die MTAThreadAttribute-Eigenschaft, die Thread.ApartmentState-Eigenschaft oder die Page.AspCompatMode-Eigenschaft verwenden.
Die Threadaffinität eines COM-Servers wird durch den Autor einer Komponente eingerichtet. In der folgenden Tabelle sind die Kombinationen für Apartmenteinstellungen für .NET-Clients und COM-Server aufgelistet. Darüber hinaus enthält die Tabelle die Marshallinganforderungen für diese Kombinationen.
.NET-Client |
COM-Server |
Anforderungen für das Marshalling |
|---|---|---|
MTA (Standard) |
MTA STA |
Interop-Marshalling. Interop-Marshalling und COM-Marshalling. |
STA |
MTA STA |
Interop-Marshalling und COM-Marshalling. Interop-Marshalling. |
Wenn ein verwalteter Client und ein nicht verwalteter Server sich in demselben Apartment befinden, werden die Daten durch den Interop-Marshallingdienst gemarshallt. Wenn der Client und der Server jedoch in unterschiedlichen Apartments initialisiert werden, ist auch COM-Marshalling erforderlich. In der folgenden Abbildung sind die Elemente eines apartmentübergreifenden Aufrufs dargestellt.
Apartmentübergreifender Aufruf zwischen .NET-Client und COM-Objekt
.gif)
Beim apartmentübergreifenden Marshalling können Sie folgendermaßen vorgehen:
Akzeptieren Sie den durch apartmentübergreifendes Marshalling verursachten Aufwand, da sich dieser nur bemerkbar macht, wenn eine große Anzahl apartmentübergreifender Aufrufe vorliegt. Damit Anrufe die Apartmentgrenze erfolgreich überschreiten können, müssen Sie die Typbibliothek der COM-Komponente registrieren.
Ändern Sie den Hauptthread, indem Sie für den Clientthread STA oder MTA festlegen. Wenn der C#-Client beispielsweise viele STA COM-Komponenten aufruft, können Sie das apartmentübergreifende Marshalling vermeiden, indem Sie für den Hauptthread STA festlegen.
.gif "Hinweis")
Hinweis:Sobald für den Thread eines C#-Clients STA festgelegt wurde, ist das apartmentübergreifende Marshalling für Aufrufe an MTA COM-Komponenten erforderlich.
Anweisungen zum expliziten Auswählen eines Apartmentmodells finden Sie unter Verwaltetes und nicht verwaltetes Threading.
Marshalling für Remoteaufrufe
Wie das apartmentübergreifende Marshalling wird auch das COM-Marshalling bei jedem Aufruf zwischen verwaltetem und nicht verwaltetem Code eingesetzt, wenn Objekte in verschiedenen Prozessen residieren. Beispiel:
Ein COM-Client, der einen verwalteten Server auf einem Remotehost aufruft, verwendet DCOM.
Ein verwalteter Client, der einen COM-Server auf einem Remotehost aufruft, verwendet DCOM.
In der folgendem Abbildung ist dargestellt, wie Interop-Marshalling und COM-Marshalling prozess- und hostgrenzenübergreifende Kommunikationschannels zur Verfügung stellen.
Prozessübergreifendes Marshalling
.gif)
Beibehaltung der Identität
Die Common Language Runtime behält die Identität verwalteter und nicht verwalteter Verweise bei. In der folgenden Abbildung ist der Fluss direkter nicht verwalteter Verweise (obere Zeile) und direkter verwalteter Verweise (untere Zeile) bei Überschreitung von Prozess- oder Hostgrenzen dargestellt.
Prozess- und hostgrenzenüberschreitende Verweise
.gif)
Die Abbildung stellt Folgendes dar:
Ein nicht verwalteter Client erhält von einem verwalteten Objekt einen Verweis auf ein COM-Objekt. Das verwaltete Objekt hat diesen Verweis zuvor von einem Remotehost erhalten. Der Remotemechanismus ist DCOM.
Ein verwalteter Client erhält von einem COM-Objekt einen Verweis auf ein verwaltetes Objekt. Das COM-Objekt hat diesen Verweis von einem Remotehost erhalten. Der Remotemechanismus ist DCOM.
Hinweis:Die exportierte Typbibliothek des verwalteten Servers muss registriert werden.
Die Anzahl der Prozessgrenzen zwischen Aufrufer und Aufgerufenem ist bedeutungslos, da für prozessinterne und für prozessexterne Aufrufe ein und derselbe direkte Verweis erfolgt.
Verwaltetes Remoting
Die Laufzeit stellt auch verwaltetes Remoting zur Verfügung, das zur Erstellung eines prozess- und hostgrenzenüberschreitenden Kommunikationschannels zwischen verwalteten Objekten verwendet werden kann. Im Rahmen des verwalteten Remoting kann ein Firewall zwischen den kommunizierenden Komponenten eingerichtet werden (siehe folgende Abbildung).
Firewallübergreifende Remoteaufrufe mit SOAP oder der TcpChannel-Klasse
.gif)
Einige nicht verwaltete Aufrufe, z. B. Aufrufe zwischen Serviced Components und COM, können über SOAP geleitet werden. Weitere Informationen zur Verwendung von verwaltetem Remoting finden Sie unter .Übersicht über .NET Framework-Remoting.
Siehe auch
Weitere Ressourcen
Standardmäßiges Marshallingverhalten