Marshaling d'interopérabilité

Le marshaling d'interopérabilité détermine la manière dont les données sont passées dans les arguments de méthode et les valeurs de retour entre la mémoire managée et la mémoire non managée lors des appels. Le marshaling d'interopérabilité est une activité runtime exécutée par le service marshaling du Common Language Runtime.

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 vue d'ensemble contient les sections suivantes :

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

• Marshaling et apartments (cloisonnés) COM

• Marshaling des appels distants

• Rubriques connexes

• Référence

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 (Component Object Model) 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, un appel de méthode d'appel de code non managé circule du code managé vers le code non managé, et jamais dans le sens inverse, sauf en cas d'utilisation de fonctions de rappel. Même si les appels de code non managé peuvent circuler uniquement du code managé vers le code non managé, les données peuvent circuler dans les deux sens en tant que paramètres d'entrée ou de sortie. 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.

Retour au début

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 à l'appelé et à l'appelant d'agir sur les mêmes données, même s'ils 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.

Clients COM et serveurs managés

Un serveur managé exporté avec une bibliothèque de types inscrite par l'Regasm.exe (outil Assembly Registration Tool) a une entrée du Registre ThreadingModel dont la valeur est 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.

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.

Clients managés et serveurs COM

Le paramètre par défaut des cloisonnements clients managés est MTA ; toutefois, le type d'application du client .NET peut changer le paramètre par défaut. Par exemple, le paramètre d'un cloisonnement client Visual Basic 2005 est STA. Vous pouvez utiliser System.STAThreadAttribute, System.MTAThreadAttribute, la propriété Thread.ApartmentState ou la propriété Page.AspCompatMode pour examiner et modifier le paramètre de cloisonnement 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.

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

Retour au début

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

• 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 de communication à distance 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 de communication à distance 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.

Communication à distance managée

Le runtime fournit également la communication à distance managée que vous pouvez utiliser pour établir un canal de communication entre des objets managés entre plusieurs hôtes et processus. La communication à distance managée 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 la communication à distance managée, consultez .NET Remoting Overview.

Retour au début

Rubriques connexes

Retour au début

Référence

System.Runtime.InteropServices

Retour au début