Interop-Marshalling

Durch das Interop-Marshalling wird gesteuert, wie während der Aufrufe Daten in Methodenargumenten und Rückgabewerten zwischen verwaltetem und nicht verwaltetem Speicher übertragen werden. Das Interop-Marshalling ist eine Laufzeitaktivität, die durch den Marshallingdienst der Common Language Runtime ausgeführt wird.

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.

Diese Übersicht enthält folgende Abschnitte:

• Plattformaufruf- und COM-Interop-Modell

• Marshalling und COM-Apartments

• Marshalling für Remoteaufrufe

• Verwandte Themen

• Verweise

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 (Component Object Model) 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 Eingabe- oder Ausgabeparameter in beide Richtungen fließen. In COM-Interop können Methodenaufrufe in beide Richtungen fließen.

Plattformaufruf- und COM-Interop-Aufruffluss

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 Standardmarshallingverhalten.

Zurück nach oben

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, auch wenn sie 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-Clients und verwaltete Server

Bei exportierten verwalteten Servern mit einer durch das Regasm.exe (Assembly Registration-Tool) 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

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.

Verwaltete Clients und COM-Server

Die Standardeinstellung für verwaltete Clientapartments lautet MTA. Diese Standardeinstellung kann jedoch durch den Anwendungstyp des .NET-Client geändert werden. Eine Visual Basic 2005-Clientapartmenteinstellung lautet z. B. STA. Um die Apartmenteinstellung für einen verwalteten Client zu überprüfen oder zu ändern, können Sie System.STAThreadAttribute, System.MTAThreadAttribute, 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

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.

  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.

Zurück nach oben

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 Distributed COM (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

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

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

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 .NET Remoting Overview.

Zurück nach oben

Verwandte Themen

Titel	Beschreibung
Standardmarshallingverhalten	Beschreibt die Regeln, die der Interop-Marshalldienst zum Marshallen von Daten verwendet.
Marshallen von Daten mit Plattformaufruf	Beschreibt, wie Methodenparameter deklariert und Argumente an Funktionen übergeben werden, die durch nicht verwaltete Bibliotheken exportiert wurden.
Marshallen von Daten mit COM-Interop	Beschreibt, wie COM-Wrapper angepasst werden, um das Verhalten beim Marshalling zu verändern.
Gewusst wie: Zuordnen von HRESULTs und Ausnahmen	Beschreibt das Zuordnen benutzerdefinierter Ausnahmen zu HRESULTs und enthält alle Zuordnungen von HRESULT zu vergleichbaren Ausnahmeklassen in .NET Framework.
Interoperation mit generischen Typen	Beschreibt, welche Aktionen bei der Verwendung generischer Typen für die COM-Interoperabilität unterstützt werden.
Interoperation mit nicht verwaltetem Code	Beschreibt die Interoperabilitätsdienste der Common Language Runtime.
Erweiterte COM-Interoperabilität	Stellt Links für weitere Informationen über das Einbinden von COM-Komponenten in die .NET Framework-Anwendung zur Verfügung.
Entwurfsüberlegungen für die Interoperation	Bietet Tipps zum Schreiben integrierter COM-Komponenten.
.NET Remoting	Beschreibt die verschiedenen Verfahren, die in .NET Framework für die Remotekommunikation zur Verfügung stehen.

Zurück nach oben

Verweise

System.Runtime.InteropServices

Zurück nach oben