Interop-Marshalling

Interop-Marshalling steuert, wie Daten in Methodenargumenten übergeben und Werte zwischen verwaltetem und nicht verwaltetem Speicher während aufrufen zurückgegeben werden. Interop-Marshalling ist eine Laufzeitaktivität, die vom Marshallingdienst der Common Language Runtime ausgeführt wird.

Die meisten Datentypen weisen gemeinsame Darstellungen sowohl im verwalteten als auch im nicht verwalteten Speicher auf. Der Interop-Marshaller behandelt diese Typen für Sie. Andere Typen können mehrdeutig sein oder überhaupt nicht im verwalteten Speicher dargestellt werden.

Ein mehrdeutiger Typ kann entweder mehrere nicht verwaltete Darstellungen aufweisen, die einem einzelnen verwalteten Typ zugeordnet sind, oder fehlende Typinformationen, z. B. die Größe eines Arrays. Bei mehrdeutigen Typen stellt der Marshaller eine Standarddarstellung und alternative Darstellungen bereit, bei denen mehrere Darstellungen vorhanden sind. Sie können explizite Anweisungen für den Marshaller angeben, um zu steuern, wie ein nicht eindeutiger Typ gemarshallt werden soll.

Plattforminvokation- und COM-Interoperabilitätsmodelle

Die Common Language Runtime bietet zwei Mechanismen für die Interoperabilität mit nicht verwalteten Code:

• Plattformaufruf, mit dem verwalteter Code Funktionen aufrufen kann, die aus einer nicht verwalteten Bibliothek exportiert wurden.
• COM-Interoperabilität, mit der verwalteter Code über Schnittstellen mit Com-Objekten (Component Object Model) interagieren kann.

Sowohl Plattformaufruf als auch COM-Interop verwenden Interop-Marshalling, um bei Bedarf Methodenargumente präzise zwischen Aufrufer und Aufgerufenem (und umgekehrt) zu bewegen. Wie die folgende Abbildung zeigt, fließt ein Aufruf der Plattformaufrufmethode von verwaltetem Code in nicht verwalteten Code und nie in die andere Richtung, außer wenn Rückruffunktionen beteiligt sind. Obwohl Aufrufe der Plattform nur von verwaltetem zu nicht verwaltetem Code fließen können, können Daten in beide Richtungen als Eingabe- oder Ausgabeparameter fließen. COM-Interop-Methodenaufrufe können in beide Richtungen fließen.

Auf der niedrigsten Ebene verwenden beide Mechanismen den gleichen Interop-Marshallingdienst. Bestimmte Datentypen werden aber ausschließlich von COM-Interop oder ausschließlich von Plattformaufrufen unterstützt. Details hierzu finden Sie unter Standardmarshallingverhalten.

Marshalling und COM Apartments

Der Interop-Marshaller marshallt Daten zwischen dem Common Language Runtime-Heap und dem nicht verwalteten Heap. Marshalling tritt auf, wenn der Anrufer und der Angerufene nicht mit derselben Dateninstanz arbeiten können. Der Interop-Marshaller ermöglicht es dem Aufrufer und dem Aufgerufenen, scheinbar an den gleichen Daten zu arbeiten, auch wenn sie jeweils eine eigene Kopie der Daten besitzen.

COM verfügt ebenfalls über einen Marshaller, der Daten zwischen COM-Apartments oder verschiedenen COM-Prozessen marshallt. Bei Aufrufen zwischen verwaltetem und nicht verwaltetem Code innerhalb des gleichen COM-Apartments ist der Interop-Marshaller als einziger Marshaller beteiligt. Bei Aufrufen zwischen verwaltetem und nicht verwaltetem Code in einem anderen COM-Apartment oder einem anderen Prozess sind sowohl der Interop-Marshaller als auch der COM-Marshaller beteiligt.

COM-Clients und verwaltete Server

Ein exportierter verwalteter Server mit einer Typbibliothek, die vom Regasm.exe (Assembly-Registrierungstool) registriert ist, hat einen ThreadingModel Registrierungseintrag, der auf Both gesetzt ist. Dieser Wert gibt an, dass der Server in einem Singlethread-Apartment (STA) oder einem Multithread-Apartment (MTA) aktiviert werden kann. Das Serverobjekt wird in derselben Wohnung wie der Anrufer erstellt, wie in der folgenden Tabelle dargestellt:

COM-Client	.NET-Server	Marshallinganforderungen
STA	Both wird zu STA.	Marshalling im gleichen Apartment
MTA	Both wird MTA.	Marshalling im gleichen Apartment

Da sich Client und Server im gleichen Apartment befinden, wickelt der Interop-Marshallingdienst automatisch das gesamte Daten-Marshalling ab. Die folgende Abbildung zeigt, wie der Interop-Marshallingdienst zwischen verwalteten und nicht verwalteten Heaps innerhalb des gleichen COM-artigen Apartments agiert:

Wenn Sie einen verwalteten Server exportieren möchten, beachten Sie, dass der COM-Client die Wohnung des Servers bestimmt. Ein verwalteter Server, der von einem COM-Client aufgerufen wird, der in einem MTA initialisiert wird, muss die Threadsicherheit sicherstellen.

Verwaltete Clients und COM-Server

Die Standardeinstellung für verwaltete Clientwohnungen ist MTA; Der Anwendungstyp des .NET-Clients kann jedoch die Standardeinstellung ändern. Angenommen, eine Visual Basic-Clientapartmenteinstellung ist STA. Sie können eine der Eigenschaften System.STAThreadAttribute, System.MTAThreadAttribute, Thread.ApartmentState oder die Eigenschaft Page.AspCompatMode verwenden, um die Apartmenteinstellung eines verwalteten Clients zu untersuchen und zu ändern.

Der Autor der Komponente legt die Threadaffinität eines COM-Servers fest. Die folgende Tabelle zeigt die Kombinationen von Apartmenteinstellungen für .NET-Clients und COM-Server. Es zeigt auch die resultierenden Marshalling-Anforderungen für die Kombinationen.

.NET-Client	COM-Server	Marshallinganforderungen
MTA (Standard)	MTA STA	Interopmarshalling Interop- und COM-Marshalling
STA	MTA STA	Interop- und COM-Marshalling Interopmarshalling

Wenn sich ein verwalteter Client und ein nicht verwalteter Server im gleichen Apartment befinden, wickelt der Interop-Marshallingdienst das gesamte Daten-Marshalling ab. Wenn Client und Server allerdings in unterschiedlichen Apartments initialisiert werden, ist auch COM-Marshalling erforderlich. Die folgende Abbildung zeigt die Elemente eines apartmentübergreifenden Aufrufs:

Für apartmentübergreifendes Marshalling können Sie Folgendes tun:

• Akzeptieren Sie den Mehraufwand für das apartmentübergreifende Marshalling, der sich nur bemerkbar macht, wenn viele Aufrufe vorhanden sind, die die Apartmentgrenze überschreiten. Sie müssen die Typbibliothek der COM-Komponente registrieren, damit Aufrufe erfolgreich die Wohnungsgrenze überschreiten.

• Ändern Sie den Hauptthread, indem Sie den Clientthread auf STA oder MTA festlegen. Wenn Ihr C#-Client z. B. viele STA COM-Komponenten aufruft, können Sie das Cross-Apartment-Marshalling vermeiden, indem Sie den Hauptthread auf STA festlegen.

  Hinweis

  Sobald der Thread eines C#-Clients auf STA festgelegt ist, erfordern Aufrufe von MTA-COM-Komponenten apartmentübergreifendes Marshalling.

Anweisungen zum expliziten Auswählen eines Apartmentmodells finden Sie unter Verwaltetes und nicht verwaltetes Threading.

Marshalling von Remoteaufrufen

Wie bei apartmentübergreifendem Marshalling ist bei jedem Aufruf zwischen verwaltetem und nicht verwaltetem Code COM-Marshalling beteiligt, wenn sich die Objekte in verschiedenen Prozessen befinden. Beispiel:

• Ein COM-Client, der einen verwalteten Server auf einem Remotehost aufruft, verwendet verteiltes COM (DCOM).
• Ein verwalteter Client, der einen COM-Server auf einem Remotehost aufruft, verwendet DCOM.

Die folgende Abbildung zeigt, wie Interop-Marshalling und COM-Marshalling Kommunikationskanäle über Prozess- und Hostgrenzen hinweg bereitstellen:

Identität beibehalten

Die Common Language Runtime behält die Identität verwalteter und nicht verwalteter Verweise bei. Die folgende Abbildung zeigt den Fluss von direkten nicht verwalteten Verweisen (oberste Zeile) und direkten verwalteten Verweisen (untere Zeile) über Prozess- und Hostgrenzen hinweg.

In dieser Abbildung:

• Ein nicht verwalteter Client ruft einen Verweis auf ein COM-Objekt aus einem verwalteten Objekt ab, das diesen Verweis von einem Remotehost abruft. Der Remotingmechanismus ist DCOM.

• Ein verwalteter Client ruft einen Verweis auf ein verwaltetes Objekt aus einem COM-Objekt ab, das diesen Verweis von einem Remotehost abruft. Der Remotingmechanismus ist DCOM.

  Hinweis

  Die exportierte Typbibliothek des verwalteten Servers muss registriert werden.

Die Anzahl der Prozessgrenzen zwischen Anrufer und Angerufenen ist irrelevant; Die gleiche direkte Referenzierung erfolgt für In-Process- und Out-of-Process-Aufrufe.

Verwaltetes Remoting

Die Laufzeit bietet auch verwaltetes Remoting, mit dem Sie einen Kommunikationskanal zwischen verwalteten Objekten über Prozess- und Hostgrenzen hinweg einrichten können. Das verwaltete Remoting kann eine Firewall zwischen den kommunizierenden Komponenten unterstützen. Dies wird in der folgenden Abbildung gezeigt.

Firewallübergreifende Remoteaufrufe mit SOAP oder der TcpChannel-Klasse

Einige nicht verwaltete Aufrufe können über SOAP geleitet werden, z. B. die Aufrufe zwischen verwalteten Komponenten und COM.

Verwandte Themen

Titel	BESCHREIBUNG
Standardmarshallingverhalten	Beschreibt die Regeln, die der Interop-Marshalling-Dienst zum Marshallen von Daten verwendet.
Daten marshallen mit Platform Invoke	Beschreibt, wie Methodenparameter deklariert und Argumente an Funktionen übergeben werden, die von nicht verwalteten Bibliotheken exportiert werden.
Marshallen von Daten mit COM-Interop	Beschreibt, wie COM-Wrapper angepasst werden können, um das Marshallverhalten zu ändern.
Gewusst wie: Migrieren von Managed-Code DCOM zu WCF	Beschreibt die Migration von DCOM zu WCF.
How to: Zuordnen von HRESULT-Werten und Ausnahmen	Beschreibt das Zuordnen benutzerdefinierter Ausnahmen zu HRESULTs und stellt die vollständige Zuordnung von jedem HRESULT zu seiner vergleichbaren Ausnahmeklasse in .NET Framework bereit.
Interoperieren mit generischen Typen	Beschreibt, welche Aktionen unterstützt werden, wenn generische Typen für die COM-Interoperabilität verwendet werden.
Interoperabilität mit nicht verwaltetem Code	Beschreibt interoperabilitätsdienste, die von der Common Language Runtime bereitgestellt werden.
Erweiterte COM-Interoperabilität	Enthält Links zu weiteren Informationen zum Integrieren von COM-Komponenten in Ihre .NET Framework-Anwendung.
Entwurfsüberlegungen für die Interoperabilität	Enthält Tipps zum Schreiben integrierter COM-Komponenten.

Referenz

System.Runtime.InteropServices