Vue d'ensemble du marshaling d'interopérabilité

Mise à jour : novembre 2007

La plupart des types de données ont des représentations communes à la fois dans la mémoire managée et la mémoire non managée. Le marshaleur d'interopérabilité gère ces types pour vous. D'autres types peuvent s'avérer ambigus ou ne sont pas du tout représentés dans la mémoire managée.

Un type ambigu peut avoir soit des multiples représentations non managées qui sont mappées à un seul type managé, soit des informations de type manquantes telles que la taille d'un tableau. Pour les types ambigus, le marshaleur fournit une représentation par défaut et des représentations alternatives là où des représentations multiples existent. Vous pouvez fournir des instructions explicites au marshaleur sur la manière dont il doit marshaler un type ambigu.

Cette rubrique démarre par une revue des modèles d'appel de code non managé et de programmation COM interop. Elle décrit la manière dont le marshaling d'interopérabilité s'intègre au marshaling COM dans la sous-rubrique Marshaling et apartments (cloisonnés) COM. Puis elle décrit l'exécution du marshaleur dans un environnement distribué dans la sous-rubrique Marshaling des appels distants.

Modèles COM Interop et d'appel de code non managé

Le Common Language Runtime fournit deux mécanismes permettant l'interopérabilité avec du code non managé :

• L'appel de code non managé, qui permet au code managé d'appeler des fonctions exportées à partir d'une bibliothèque non managée.

• COM interop, qui permet au code managé d'interagir avec des objets COM par l'intermédiaire d'interfaces.

L'appel de code non managé et COM interop utilisent le marshaling d'interopérabilité pour envoyer et retourner correctement des arguments de méthode entre l'appelant et l'appelé, si cela est requis. Comme le montre l'illustration suivante, hormis les cas utilisant les fonctions de rappel, un appel de méthode d'appel de code non managé circule à partir du code managé vers le code non managé, jamais dans le sens inverse. Même si les appels de code non managé ne peuvent circuler qu'à partir du code managé vers le code non managé, les données peuvent circuler dans les deux directions en tant que paramètres In ou Out. Les appels de méthode COM interop peuvent circuler dans l'une ou l'autre direction.

Flux d'appel de code non managé et COM interop

Au niveau le plus bas, ces deux mécanismes utilisent le même service marshaling d'interopérabilité ; cependant, certains types de données sont pris en charge en mode exclusif par COM interop ou par l'appel de code non managé. Pour plus d'informations, consultez Comportement de marshaling par défaut.

Marshaling et apartments (cloisonnés) COM

Le marshaleur d'interopérabilité marshale des données entre le tas du Common Language Runtime et le tas non managé. Le marshaling se produit chaque fois que l'appelé et l'appelant ne peuvent agir sur la même instance de données. Le marshaleur d'interopérabilité permet aussi bien à l'appelé et à l'appelant d'agir sur les mêmes données, même si l'appelé et l'appelant possèdent leur copie respective des données.

COM possède également un marshaleur qui marshale les données entre les apartments (cloisonnés) COM ou différents processus COM. Lors d'un appel entre du code managé et du code non managé à l'intérieur du même apartment (cloisonné) COM, le marshaleur d'interopérabilité est le seul marshaleur impliqué. Lors d'un appel entre du code managé et du code non managé dans un apartment (cloisonné) COM différent ou un processus différent, le marshaleur COM et le marshaleur d'interopérabilité sont tous deux impliqués.

Client COM et serveur .NET

Un serveur managé exporté avec une bibliothèque de types enregistrée par l' Outil Assembly Registration Tool (Regasm.exe) a une entrée de Registre ThreadingModel définie à Both. Cette valeur indique que le serveur peut être activé en mode STA (Single-Threaded Apartment) ou en mode MTA (Multithreaded Apartment). L'objet serveur est créé dans le même apartment (cloisonné) que son appelant, comme le montre le tableau suivant.

Client COM	Serveur .NET	Configuration de marshaling
STA	Both devient STA.	Marshaling dans le même apartment (cloisonné).
MTA	Both devient MTA.	Marshaling dans le même apartment (cloisonné).

Comme le client et le serveur se trouvent dans le même apartment (cloisonné), le service marshaling d'interopérabilité gère automatiquement tout le marshaling des données. L'illustration suivante montre le fonctionnement du service marshaling d'interopérabilité entre les tas managés et non managés à l'intérieur du même apartment (cloisonné) de style COM.

Processus de marshaling dans le même apartment (cloisonné)

Si vous envisagez d'exporter un serveur managé, gardez à l'esprit que le client COM détermine l'apartment (cloisonné) du serveur. Un serveur managé appelé par un client COM initialisé dans un MTA doit garantir la sécurité des threads.

Client .NET et serveur COM

Le paramètre par défaut des apartments (cloisonnés) clients .NET est MTA ; cependant, le type d'application du client .NET peut changer le paramètre par défaut. Par exemple, STA est un paramètre d'apartment (cloisonné) client Visual Basic 2005. Vous pouvez utiliser STAThreadAttribute, MTAThreadAttribute, la propriété Thread.ApartmentState ou la propriété Page.AspCompatMode pour examiner et modifier le paramètre d'apartment d'un client managé.

L'auteur du composant définit l'affinité du thread d'un serveur COM. Le tableau suivant montre les combinaisons de paramètres d'apartment (cloisonné) pour les clients .NET et les serveurs COM. Le tableau illustre également les configurations de marshaling qui résultent de ces associations.

Client .NET	Serveur COM	Configuration de marshaling
MTA (par défaut)	MTA STA	Marshaling d'interopérabilité. Marshaling COM et d'interopérabilité.
STA	MTA STA	Marshaling COM et d'interopérabilité. Marshaling d'interopérabilité.

Lorsqu'un client managé et un serveur non managé se trouvent dans le même apartment (cloisonné), le service marshaling d'interopérabilité gère tout le marshaling des données. Cependant, lorsque le client et le serveur sont initialisés dans des apartments (cloisonnés) différents, le marshaling COM est également requis. L'illustration suivante montre les éléments d'un appel d'intercloisonnement.

Appel d'intercloisonnement entre un client .NET et un objet COM.

Pour le marshaling d'intercloisonnement, vous pouvez procéder comme suit :

• Acceptez la charge mémoire du marshaling d'intercloisonnement qui se remarque uniquement lorsqu'il y a plusieurs appels au-delà des limites. Vous devez inscrire la bibliothèque de types du composant COM pour que les appels franchissent les limites de l'apartment (cloisonné).

• Modifiez le thread principal en définissant le thread client sur STA ou MTA. Par exemple, si votre client C# appelle plusieurs composants COM STA, vous pouvez éviter le marshaling d'intercloisonnement en définissant le thread principal sur STA.

  Remarque :
  Une fois que le thread d'un client C# est défini sur STA, des appels vers les composants COM MTA nécessitent un marshaling d'intercloisonnement.

Pour obtenir des instructions sur la sélection explicite d'un modèle cloisonné, consultez Threading managé et non managé.

Marshaling des appels distants

Comme pour le marshaling d'intercloisonnement, le marshaling COM est impliqué dans chaque appel entre du code managé et du code non managé à chaque fois que les objets résident dans des processus séparés. Par exemple :

• Un client COM qui appelle un serveur managé sur un hôte distant utilise DCOM.

• Un client managé qui appelle un serveur COM sur un hôte distant utilise DCOM.

L'illustration suivante montre comment le marshaling d'interopérabilité et le marshaling COM fournissent des canaux de communication entre plusieurs hôtes et processus.

Marshaling interprocessus

Préservation d'identité

Le Common Language Runtime préserve l'identité des références managées et non managées. L'illustration suivante montre le flux des références non managées directes (ligne supérieure) et des références managées directes (ligne inférieure) entre plusieurs hôtes et processus.

Passage de référence entre plusieurs hôtes et processus

Dans cette illustration :

• Un client non managé envoie une référence à un objet COM à partir d'un objet managé qui reçoit cette référence d'un hôte distant. Le mécanisme d'accès distant est DCOM.

• Un client managé envoie une référence à un objet managé à partir d'un objet COM qui reçoit cette référence d'un hôte distant. Le mécanisme d'accès distant est DCOM.

  Remarque :
  La bibliothèque de types exportée du serveur managé doit être inscrite.

Le nombre de limites de processus entre l'appelant et l'appelé n'est pas pertinent ; le même référencement direct se produit pour les appels in-process et out-of-process.

Accès distant managé

Le runtime fournit également l'accès distant managé que vous pouvez utiliser pour établir un canal de communication entre des objets managés entre plusieurs hôtes et processus. L'accès distant managé peut prendre en charge un pare-feu entre les composants qui communiquent comme le montre l'illustration suivante.

Appels distants entre des pare-feu à l'aide de SOAP ou de la classe TcpChannel

Certains appels non managés peuvent être transmis via SOAP, tels que les appels entre composants pris en charge et COM. Pour plus d'informations sur l'utilisation de l'accès distant managé, consultez Vue d'ensemble de l'accès distant .NET Framework.

Voir aussi

Autres ressources

Marshaling d'interopérabilité

Comportement de marshaling par défaut

Marshaling de données à l'aide de l'appel de plate-forme

Marshaling de données à l'aide de COM Interop