Marshaling d’interopérabilité

Le marshaling d’interopérabilité détermine la façon dont les données sont passées dans les arguments des méthodes, 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é qui a lieu au moment de l’exécution, et qui est effectuée par le service de marshaling du Common Language Runtime.

La plupart des types de données ont des représentations communes 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 être ambigus ou non représentés dans la mémoire managée.

Un type ambigu peut avoir plusieurs représentations non managées qui correspondent à un seul type managé ou bien ne pas avoir d'informations de type (par exemple, la taille d'un tableau). Pour les types ambigus, le marshaleur fournit une représentation par défaut et des représentations alternatives où plusieurs représentations existent. Vous pouvez fournir des instructions explicites au marshaleur sur la façon de marshaler un type ambigu.

Appel de code non managé et modèles d'interopérabilité COM

Le common language runtime fournit deux mécanismes d'interopérabilité avec le 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 les objets COM via des interfaces.

L’appel de code non managé et COM Interop utilisent tous deux le marshaling d’interopérabilité pour faire passer les arguments des méthodes de l’appelant à l’appelé, puis dans l’autre sens si nécessaire. Comme le montre l’illustration suivante, un appel de méthode d’appel de code non managé passe du code managé au code non managé et jamais dans l’autre sens, sauf quand des fonctions de rappel sont impliquées. Même si les appels de code non managé peuvent uniquement passer du code managé au 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 les deux sens.

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

Marshaling et cloisonnements COM

Le marshaleur d’interopérabilité marshale les données entre le tas du common langage runtime et le tas non managé. Le marshaling se produit chaque fois que l’appelant et l’appelé ne peuvent pas agir sur une même instance de données. Le marshaleur d’interopérabilité permet à l’appelant et à l’appelé de sembler utiliser les mêmes données, même s’ils ont chacun leur propre copie des données.

COM a également un marshaleur qui marshale les données entre les cloisonnements COM ou différents processus COM. Lors d’un appel entre du code managé et du code non managé au sein d’un même cloisonnement 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 cloisonnements COM différent ou un processus différent, le marshaleur d’interopérabilité et le marshaleur COM sont tous les deux impliqués.

Clients COM et serveurs managés

L’entrée de Registre ThreadingModel d’un serveur managé exporté avec une bibliothèque de types inscrite par l’outil Regasm.exe (outil d’inscription d’assemblys) a la valeur Both. Cette valeur indique que le serveur peut être activé dans un thread unique cloisonné (STA) ou dans un multithread cloisonné (MTA). L’objet serveur est créé dans le même cloisonnement que son appelant, comme indiqué dans le tableau suivant :

Comme le client et le serveur se trouvent dans le même cloisonnement, le service de marshaling d’interopérabilité gère automatiquement tout le marshaling des données. L’illustration suivante montre le service de marshaling d’interopérabilité agissant entre le tas managés et le tas non managé au sein du même cloisonnement de style COM.

Si vous prévoyez d'exporter un serveur managé, n'oubliez pas que le client COM détermine le cloisonnement du serveur. Un serveur managé appelé par un client COM initialisé dans un MTA doit garantir la cohérence des threads.

Clients managés et serveurs COM

Le paramètre par défaut des cloisonnements de clients managés est MTA. Toutefois, le type d'application du client .NET peut modifier le paramètre par défaut. Par exemple, le paramètre de cloisonnement d’un client Visual Basic est STA. Vous pouvez utiliser l'attribut System.STAThreadAttribute, l'attribut 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é de thread d'un serveur COM. Le tableau suivant montre les combinaisons de paramètres de cloisonnement pour les serveurs COM et les clients .NET. Il montre également la configuration de marshaling requise qui en résulte pour les combinaisons.

Quand un client managé et un serveur non managé se trouvent dans un même cloisonnement, le service de marshaling d’interopérabilité gère tout le marshaling des données. Cependant, quand le client et le serveur sont initialisés dans des cloisonnements différents, le marshaling COM est également nécessaire. L’illustration suivante montre les éléments d’un appel intercloisonnements :

Pour le marshaling intercloisonnements, vous pouvez procéder comme suit :

• Acceptez la surcharge liée au marshaling intercloisonnements, qui se remarque seulement quand de nombreux appels dépassent la limite. Vous devez inscrire la bibliothèque de types du composant COM pour que les appels puissent franchir les limites des cloisonnements.

• 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 intercloisonnements en définissant le thread principal sur STA.

  Notes

  Une fois le thread d’un client C# défini sur STA, les appels aux composants COM MTA nécessiteront un marshaling intercloisonnements.

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

Marshaling des appels distants

Comme pour le marshaling intercloisonnements, le marshaling COM est impliqué dans chaque appel effectué entre du code managé et du code non managé chaque fois que les objets se trouvent dans des processus distincts. Par exemple :

• Un client COM qui appelle un serveur managé sur un hôte distant utilise le modèle DCOM (Distributed COM).
• Un client managé qui appelle un serveur COM sur un hôte distant utilise le modèle DCOM.

L’illustration suivante montre comment le marshaling d’interopérabilité et le marshaling COM fournissent des canaux de communication entre les limites des hôtes et des processus :

Conservation 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 du haut) et des références managées directes (ligne du bas) entre plusieurs hôtes et processus.

Dans cette illustration :

• Un client non managé obtient une référence à un objet COM provenant 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é obtient une référence à un objet managé provenant d'un objet COM qui reçoit cette référence d'un hôte distant. Le mécanisme de communication à distance est DCOM.

  Notes

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

Le nombre de limites de processus entre l'appelant et l'appelé est sans importance. Le même référencement direct se produit pour les appels de type in-process et out-of-process.

Communication à distance managée

Le runtime fournit également une communication à distance managée que vous pouvez utiliser pour établir un canal de communication entre des objets managés de plusieurs hôtes et processus. La communication à distance managée peut prendre en charge un pare-feu entre des composants qui communiquent, comme le montre l’illustration suivante :

Appels distants à travers des pare-feu avec SOAP ou la classe TcpChannel

Certains appels non managés peuvent être transmis par le biais de SOAP, tels que les appels entre composants pris en charge et COM.

Rubriques connexes

Informations de référence

System.Runtime.InteropServices