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é d’exécution effectuée par le service de marshaling du Common Language Runtime.

La plupart des types de données ont des représentations courantes dans la mémoire managée et 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 du tout en mémoire managée.

Un type ambigu peut avoir plusieurs représentations non managées qui mappent à un type managé unique, ou des informations de type manquantes, telles que la taille d’un tableau. Pour les types ambigus, le marshaller fournit une représentation par défaut et d’autres représentations 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 du code non managé :

• Appel de plateforme, qui permet au code managé d’appeler des fonctions exportées à partir d’une bibliothèque non managée.
• Interopérabilité COM, qui permet au code managé d’interagir avec des objets COM (Component Object Model) 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 l’illustre l’illustration suivante, un appel de méthode d'invocation de plateforme passe du code géré au code non managé et jamais dans l'autre sens, sauf lorsque les fonctions de rappel sont impliquées. Même si seule la communication du code managé vers le code non managé est possible via les appels d'appel de plate-forme, 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.

Marshalling et COM Appartements

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 fonctionner sur la 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 d’un serveur managé exporté avec une bibliothèque de types inscrite par l’outil ThreadingModel 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 appartement que son appelant, comme indiqué dans le tableau suivant :

Étant donné que le client et le serveur se trouvent dans le même appartement, le service de gestion des données d’interopérabilité gère automatiquement toutes les opérations de gestion 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 envisagez d’exporter un serveur managé, sachez que le client COM détermine l’appartement 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 pour les appartements clients gérés est MTA ; Toutefois, le type d’application du client .NET peut modifier le paramètre par défaut. Par exemple, un paramètre d’appartement 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 inter-appartements :

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 franchissent correctement la limite de l’appartement.

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

  Remarque

  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 distributed COM (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 les limites des hôtes et des processus :

Préservation de l’identité

Le Common Language Runtime conserve l’identité des références managées et non managées. L’illustration suivante montre le flux de références directes non managées (ligne supérieure) et de références managées directes (ligne inférieure) entre les limites du processus et de l’hôte.

Transfert de référence du

Dans cette illustration :

• Un client non managé obtient une référence à un objet COM à partir d’un objet managé qui obtient cette référence à partir d’un hôte distant. Le mécanisme de communication à distance est DCOM.

• Un client managé obtient une référence à un objet managé à partir d’un objet COM qui obtient cette référence à partir 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’a pas de pertinence ; le même référencement direct se produit pour les appels internes au processus et externes au processus.

Communication à distance managée

Le runtime fournit également une communication à distance managée, que vous pouvez utiliser pour établir un canal de communication entre les objets managés entre les limites du processus et de l’hôte. La communication à distance managée peut prendre en charge un pare-feu entre les composants de communication, comme l’illustre l’illustration suivante :

Appels distants traversant des pare-feu à l’aide de SOAP ou de la classe TcpChannel

Certains appels non managés peuvent être canalnés via SOAP, tels que les appels entre les composants service et COM.

Rubriques connexes

Référence

System.Runtime.InteropServices