Interop-Marshalling

Interop-Marshalling steuert, wie Daten in Methodenargumenten und Rückgabewerten zwischen verwaltetem und nicht verwaltetem Arbeitsspeicher während Aufrufen übergeben werden. Interop-Marshalling ist eine Laufzeitaktivität, die vom Marshallingdienst der Common Language Runtime ausgeführt wird.

Die meisten Datentypen verfügen über gemeinsame Darstellungen im verwalteten und nicht verwalteten Speicher. Der Interop-Marshaller behandelt diese Typen für Sie. Andere Typen können im verwalteten Speicher nicht eindeutig oder gar nicht dargestellt sein.

Ein nicht eindeutiger Typ kann entweder mehrere nicht verwaltete Darstellungen besitzen, die einem einzelnen verwalteten Typ zugeordnet werden, oder ihm können Typinformationen fehlen, wie z. B. die Größe eines Arrays. Für nicht eindeutige Typen stellt der Marshaller eine Standarddarstellung bereit. Sind mehrere Darstellungen vorhanden, werden alternative Darstellungen bereitgestellt. Sie können explizite Anweisungen für den Marshaller angeben, um zu steuern, wie ein nicht eindeutiger Typ gemarshallt werden soll.

Plattformaufruf und COM-Interop-Modelle

Die Common Language Runtime stellt zwei Mechanismen für die Interoperation mit nicht verwaltetem Code bereit:

• Plattformaufruf, wodurch verwalteter Code Funktionen aufrufen kann, die aus einer nicht verwalteten Bibliothek exportiert wurden.
• COM-Interop, wodurch 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 Methodenaufruf eines Plattformaufrufs vom verwalteten zum nicht verwalteten Code und niemals umgekehrt, es sei denn, dass Rückruffunktionen beteiligt sind. Obwohl Plattformaufrufe nur vom verwalteten zum nicht verwalteten Code fließen können, können Daten als Ein-oder Ausgabeparameter in beide Richtungen 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 Aufrufer und der Aufgerufene nicht an der Instanz von Daten 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 vom Assembly Registration-Tool (Regasm.exe) registrierten Typbibliothek besitzt einen auf Both festgelegten ThreadingModel-Registrierungseintrag. Dieser Wert gibt an, dass der Server in einem Singlethread-Apartment (STA) oder einem Multithread-Apartment (MTA) aktiviert werden kann. Wie in der folgenden Tabelle dargestellt, wird das Serverobjekt im selben Apartment wie sein Aufrufer erstellt.

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 planen, einen verwalteten Server zu exportieren, sollten Sie daran denken, dass der COM-Client das Apartment des Servers bestimmt. Ein von einem COM-Client aufgerufener und in einem MTA initialisierter verwalteter Server muss Threadsicherheit sicherstellen.

Verwaltete Clients und COM-Server

Die Standardeinstellung für verwaltete Clientapartments 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. Sie zeigt außerdem die resultierenden Marshallinganforderungen für die Kombinationen.

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 Apartmentgrenze überschreiten können.

• Ändern Sie den Hauptthread, indem den Clientthread auf STA oder MTA festlegen. Wenn z. B. Ihr C#-Client viele STA-COM-Komponenten aufruft, können Sie apartmentübergreifendes 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.

Anleitungen zum expliziten Auswählen eines Apartmentmodells finden Sie unter Managed and Unmanaged Threading (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. Zum 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:

Beibehalten der Identität

Die Common Language Runtime behält die Identität verwalteter und nicht verwalteter Verweise bei. Die folgende Abbildung zeigt den Fluss direkter, nicht verwalteter Verweise (obere Zeile) und direkter, verwalteter Verweise (untere Zeile) über Prozess- und Hostgrenzen hinweg.

In dieser Abbildung:

• Ein nicht verwalteter Client ruft einen Verweis auf ein COM-Objekt von 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 von einem COM-Objekt ab, das diesen Verweis von einem Remotehost abruft. Der Remotingmechanismus ist DCOM.

  Hinweis

  Die exportierte Typbibliothek des verwalteten Servers muss registriert sein.

Die Anzahl der Prozessgrenzen zwischen Aufrufer und Aufgerufenem ist irrelevant. Dieselbe direkte Referenzierung tritt bei prozessinternen und -externen Aufrufen auf.

Verwaltetes Remoting

Die Laufzeit bietet auch verwaltetes Remoting, das Sie zum Einrichten eines Kommunikationskanals zwischen verwalteten Objekten über Prozess- und Hostgrenzen hinweg verwenden 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 durch SOAP geleitet werden, z.B. die Aufrufe zwischen Serviced Components und COM.

Verwandte Themen

Referenz

System.Runtime.InteropServices