Partager via

Comportement de marshaling par défaut

Le marshaling d’interopérabilité agit sur les règles qui définissent le comportement des données associées aux paramètres de méthode quand elles sont passées de la mémoire managée à la mémoire non managée. Ces règles intégrées contrôlent les activités de marshaling comme les transformations de types de données, le fait qu’un appelant puisse changer les données passées et retourner ces changements à l’appelant, ainsi que les circonstances dans lesquelles le marshaleur fournit des optimisations de performances.

Cette section décrit les caractéristiques du comportement par défaut du service de marshaling d’interopérabilité. Il présente des informations détaillées sur les tableaux de marshaling, les types booléens, les types char, les délégués, les classes, les objets, les chaînes et les structures.

Remarque

Le marshaling des types génériques n’est pas pris en charge. Pour plus d’informations, consultez Interopération à l’aide de types génériques.

Gestion de la mémoire avec le marshaleur d’interopérabilité

Le marshaleur d’interopérabilité tente toujours de libérer de la mémoire allouée par du code non managé. Ce comportement est conforme aux règles de gestion de la mémoire COM, mais diffère des règles qui régissent le langage C++natif.

La confusion peut survenir si vous prévoyez un comportement C++ natif (sans libération de mémoire) lors de l’utilisation d’un appel de plateforme, ce qui libère automatiquement la mémoire pour les pointeurs. Par exemple, l’appel de la méthode non managée suivante à partir d’une DLL C++ ne libère pas automatiquement de mémoire.

Signature non managée

BSTR MethodOne (BSTR b) {
     return b;
}

Toutefois, si vous définissez la méthode comme prototype d’appel de plateforme, remplacez chaque BSTR type par un String type et appelez MethodOne, le Common Language Runtime tente de libérer b deux fois. Vous pouvez modifier le comportement de l'assemblage en utilisant des types IntPtr plutôt que des types String.

Le runtime utilise toujours la méthode CoTaskMemFree sur Windows et la méthode free sur d'autres plateformes pour libérer de la mémoire. Si la mémoire avec laquelle vous travaillez n’a pas été allouée avec la CoTaskMemAlloc méthode sur Windows ou malloc sur d’autres plateformes, vous devez utiliser une IntPtr mémoire et libérer manuellement la mémoire à l’aide de la méthode appropriée. De même, vous pouvez éviter la libération automatique de la mémoire dans les situations où la mémoire ne doit jamais être libérée, par exemple lors de l’utilisation de la GetCommandLine fonction de Kernel32.dll, qui retourne un pointeur vers la mémoire du noyau. Pour plus d’informations sur la libération manuelle de la mémoire, consultez l’exemple De mémoires tampons.

Marshaling par défaut pour les classes

Les classes peuvent être marshalées uniquement par l’interopérabilité COM et sont toujours marshalées en tant qu’interfaces. Dans certains cas, l’interface utilisée pour marshaler la classe est appelée interface de classe. Pour plus d’informations sur la substitution de l’interface de classe avec une interface de votre choix, consultez Présentation de l’interface de classe.

Passage de classes à COM

Lorsqu’une classe managée est passée à COM, le marshaller d’interopérabilité encapsule automatiquement la classe avec un proxy COM et transmet l’interface de classe produite par le proxy à l’appel de méthode COM. Le proxy délègue ensuite tous les appels sur l’interface de classe à l’objet managé. Le proxy expose également d’autres interfaces qui ne sont pas explicitement implémentées par la classe. Le proxy implémente automatiquement des interfaces telles que IUnknown et IDispatch au nom de la classe.

Passage de classes à .NET Code

Les coclasses ne sont généralement pas utilisées comme arguments de méthode dans COM. Au lieu de cela, une interface par défaut est généralement passée à la place de la coclasse.

Quand une interface est passée dans du code managé, le marshaleur d’interopérabilité est responsable de l’encapsulation de l’interface avec le wrapper approprié et du passage du wrapper à la méthode managée. Déterminer le wrapper à utiliser peut être difficile. Chaque instance d’un objet COM a un wrapper unique unique, quel que soit le nombre d’interfaces implémentées par l’objet. Par exemple, un seul objet COM qui implémente cinq interfaces distinctes n’a qu’un seul wrapper. Le même wrapper expose les cinq interfaces. Si deux instances de l’objet COM sont créées, deux instances du wrapper sont créées.

Pour que le wrapper conserve le même type durant toute sa durée de vie, le marshaleur d’interopérabilité doit identifier le bon wrapper la première fois qu’une interface exposée par l’objet est passée via le marshaleur. Le marshaller identifie l’objet en examinant l’une des interfaces que l’objet implémente.

Par exemple, le marshaleur détermine que le wrapper de classe doit être utilisé pour encapsuler l’interface qui a été passée dans le code managé. Lorsque l’interface est passée d’abord par le marshaller, le marshaller vérifie si l’interface provient d’un objet connu. Cette vérification se produit dans deux situations :

  • Une interface est implémentée par un autre objet managé passé à COM ailleurs. Le marshaller peut facilement identifier les interfaces exposées par des objets managés et est en mesure de faire correspondre l’interface avec l’objet managé qui fournit l’implémentation. L’objet managé est ensuite passé à la méthode et aucun wrapper n’est nécessaire.

  • Un objet qui a déjà été encapsulé implémente l’interface. Pour déterminer si c’est le cas, le marshaller interroge l’objet pour son IUnknown interface et compare l’interface retournée aux interfaces d’autres objets déjà encapsulés. Si l’interface est identique à celle d’un autre wrapper, les objets ont la même identité et le wrapper existant est passé à la méthode.

Si une interface ne provient pas d’un objet connu, le marshaller effectue les opérations suivantes :

  1. Le marshaller interroge l’objet pour l’interface IProvideClassInfo2 . S’il est fourni, le marshaller utilise le CLSID retourné par IProvideClassInfo2.GetGUID pour identifier la coclasse fournissant l’interface. Avec le CLSID, le marshaleur peut localiser le wrapper à partir du Registre si l’assembly a été inscrit auparavant.

  2. Le marshaller interroge l’interface pour l’interface IProvideClassInfo. S’il est fourni, le marshaller utilise le ITypeInfo renvoyé par IProvideClassInfo.GetClassinfo pour déterminer le CLSID de la classe qui expose l’interface. Le marshaller peut utiliser le CLSID pour localiser les métadonnées du wrapper.

  3. Si le marshaller ne peut toujours pas identifier la classe, il encapsule l’interface avec une classe wrapper générique appelée System.__ComObject.

Marshaling par défaut pour les délégués

Un délégué managé est marshalisé en tant qu’interface COM ou en tant que pointeur de fonction, selon le mécanisme d'appel.

  • Pour un appel de code non managé, un délégué est marshalé par défaut comme pointeur de fonction non managée.

  • Pour l’interopérabilité COM, un délégué est marshalisé en tant qu’interface COM de type _Delegate par défaut. L’interface _Delegate est définie dans la bibliothèque de types Mscorlib.tlb et contient la Delegate.DynamicInvoke méthode, qui vous permet d’appeler la méthode référencée par le délégué.

Le tableau suivant montre les options de marshaling pour le type de données délégué managé. L'attribut MarshalAsAttribute fournit plusieurs valeurs d'énumération UnmanagedType pour marshaler les délégués.

Type d’énumération Description du format non managé
UnmanagedType.FunctionPtr Pointeur de fonction non managé.
UnmanagedType.Interface Interface de type _Delegate, telle que définie dans Mscorlib.tlb.

Considérez l'exemple de code suivant où les méthodes de DelegateTestInterface sont exportées vers une bibliothèque de types COM. Remarquez que seuls les délégués marqués avec le mot clé ref (ou ByRef) sont passés comme paramètres d'entrée/sortie.

using System;
using System.Runtime.InteropServices;

public interface DelegateTest {
void m1(Delegate d);
void m2([MarshalAs(UnmanagedType.Interface)] Delegate d);
void m3([MarshalAs(UnmanagedType.Interface)] ref Delegate d);
void m4([MarshalAs(UnmanagedType.FunctionPtr)] Delegate d);
void m5([MarshalAs(UnmanagedType.FunctionPtr)] ref Delegate d);
}

Représentation de bibliothèque de types

importlib("mscorlib.tlb");
interface DelegateTest : IDispatch {
[id(…)] HRESULT m1([in] _Delegate* d);
[id(…)] HRESULT m2([in] _Delegate* d);
[id(…)] HRESULT m3([in, out] _Delegate** d);
[id()] HRESULT m4([in] int d);
[id()] HRESULT m5([in, out] int *d);
   };

Un pointeur de fonction peut être déréférencé, tout comme n’importe quel autre pointeur de fonction non managé peut être déréférencé.

Dans cet exemple, quand les deux délégués sont marshalés comme UnmanagedType.FunctionPtr, le résultat est un int et un pointeur vers un int. Comme les types délégués sont marshalés, int représente ici un pointeur vers une valeur void (void*), qui est l’adresse du délégué en mémoire. En d’autres termes, ce résultat est spécifique aux systèmes Windows 32 bits, car int ici représente la taille du pointeur de fonction.

Remarque

Une référence au pointeur fonction d’un délégué managé compris dans du code non managé n’empêche pas le common language runtime d’effectuer le garbage collection sur l’objet managé.

Par exemple, le code suivant est incorrect, car la référence à l’objet cb , passée à la SetChangeHandler méthode, ne reste cb pas vivante au-delà de la durée de vie de la Test méthode. Une fois l'objet cb collecté, le pointeur fonction passé à SetChangeHandler n'est plus valide.

public class ExternalAPI {
   [DllImport("External.dll")]
   public static extern void SetChangeHandler(
      [MarshalAs(UnmanagedType.FunctionPtr)]ChangeDelegate d);
}
public delegate bool ChangeDelegate([MarshalAs(UnmanagedType.LPWStr) string S);
public class CallBackClass {
   public bool OnChange(string S){ return true;}
}
internal class DelegateTest {
   public static void Test() {
      CallBackClass cb = new CallBackClass();
      // Caution: The following reference on the cb object does not keep the
      // object from being garbage collected after the Main method
      // executes.
      ExternalAPI.SetChangeHandler(new ChangeDelegate(cb.OnChange));
   }
}

Pour compenser la collecte de déchets inattendue, l’appelant doit s’assurer que l’objet cb est maintenu en vie tant que le pointeur de fonction non géré est en cours d’utilisation. Si vous le souhaitez, vous pouvez avoir le code non managé notifier le code managé lorsque le pointeur de fonction n’est plus nécessaire, comme l’illustre l’exemple suivant.

internal class DelegateTest {
   CallBackClass cb;
   // Called before ever using the callback function.
   public static void SetChangeHandler() {
      cb = new CallBackClass();
      ExternalAPI.SetChangeHandler(new ChangeDelegate(cb.OnChange));
   }
   // Called after using the callback function for the last time.
   public static void RemoveChangeHandler() {
      // The cb object can be collected now. The unmanaged code is
      // finished with the callback function.
      cb = null;
   }
}

Marshaling par défaut des types valeur

La plupart des types valeur, comme les nombres entiers et à virgule flottante, sont blittables et ne nécessitent pas de marshaling. D’autres types non blittables ont des représentations différentes selon qu’ils sont en mémoire managée et non managée, et nécessitent un marshaling. D’autres types nécessitent une mise en forme explicite sur la limite d’interopérabilité.

Cette section fournit des informations sur les types de valeurs mis en forme suivants :

En plus de décrire les types mis en forme, cette rubrique liste les types valeur système qui ont un comportement de marshaling inhabituel.

Un type mis en forme est un type complexe qui contient des informations qui contrôlent explicitement la disposition de ses membres en mémoire. Les informations de disposition des membres sont fournies à l’aide de l’attribut StructLayoutAttribute . La disposition peut être l’une des valeurs d’énumération suivantes LayoutKind :

  • LayoutKind.Auto

    Indique que le Common Language Runtime est libre de réorganiser les membres du type pour optimiser l'efficacité. Toutefois, lorsqu’un type valeur est passé à du code non managé, la disposition des membres est prévisible. Une tentative d'organiser automatiquement une telle structure provoque une exception.

  • LayoutKind.Sequential

    Indique que les membres du type doivent être disposés dans une mémoire non managée dans le même ordre dans lequel ils apparaissent dans la définition de type managé.

  • LayoutKind.Explicit

    Indique que les membres sont disposés selon le FieldOffsetAttribute fourni avec chaque champ.

Types valeur utilisés dans un appel de plateforme

Dans l’exemple suivant, les types Point et Rect fournissent des informations sur la disposition des membres à l’aide de StructLayoutAttribute.

Imports System.Runtime.InteropServices
<StructLayout(LayoutKind.Sequential)> Public Structure Point
   Public x As Integer
   Public y As Integer
End Structure
<StructLayout(LayoutKind.Explicit)> Public Structure Rect
   <FieldOffset(0)> Public left As Integer
   <FieldOffset(4)> Public top As Integer
   <FieldOffset(8)> Public right As Integer
   <FieldOffset(12)> Public bottom As Integer
End Structure

using System.Runtime.InteropServices;
[StructLayout(LayoutKind.Sequential)]
public struct Point {
   public int x;
   public int y;
}

[StructLayout(LayoutKind.Explicit)]
public struct Rect {
   [FieldOffset(0)] public int left;
   [FieldOffset(4)] public int top;
   [FieldOffset(8)] public int right;
   [FieldOffset(12)] public int bottom;
}

Lorsqu’ils sont marshalés en code non managé, ces types mis en forme sont marshalés en tant que structures de style C. Cela permet d’appeler facilement une API non managée qui a des arguments de structure. Par exemple, les structures POINT et RECT peuvent être passées à la fonction API Microsoft Windows PtInRect comme suit :

BOOL PtInRect(const RECT *lprc, POINT pt);

Vous pouvez passer des structures à l'aide de la définition d'appel de code non managé suivante :

Friend Class NativeMethods
    Friend Declare Auto Function PtInRect Lib "User32.dll" (
        ByRef r As Rect, p As Point) As Boolean
End Class

internal static class NativeMethods
{
   [DllImport("User32.dll")]
   internal static extern bool PtInRect(ref Rect r, Point p);
}

Le type de valeur Rect doit être passé par référence, car l’API non managée s’attend à ce qu’un pointeur vers un RECT soit transmis à la fonction. Le type valeur Point est passé par valeur, car l'API non managée s'attend à ce que le POINT soit passé à la pile. Cette différence subtile est très importante. Les références sont passées au code non managé comme des pointeurs. Les valeurs sont passées au code non managé sur la pile.

Remarque

Lorsqu’un type mis en forme est marshalé en tant que structure, seuls les champs du type sont accessibles. Si le type a des méthodes, des propriétés ou des événements, ils sont inaccessibles à partir du code non managé.

Les classes peuvent également être converties en code non managé en tant que structures à la manière de C, à condition qu'elles aient une disposition des membres fixe. Les informations de disposition de membre pour une classe sont également fournies avec l’attribut StructLayoutAttribute . La principale différence entre les types de valeur avec une disposition fixe et les classes avec une disposition fixe est la façon dont ils sont marshallés vers du code non managé. Les types valeur sont passés par valeur (dans la pile). Toutes les modifications apportées par l'appelé aux membres du type ne sont donc pas vues par l'appelant. Les types référence sont passés par référence (une référence au type est passée sur la pile). Toutes les modifications apportées par l'appelé aux membres d'un type blittable sont donc vues par l'appelant.

Remarque

Si un type référence possède des membres de type non blittable, la conversion est requise deux fois : la première fois quand un argument est passé du côté non managé, la seconde fois lors du retour de l'appel. En raison de cette charge mémoire supplémentaire, les paramètres In/Out doivent être explicitement appliqués à un argument si l'appelant veut voir les modifications apportées par l'appelé.

Dans l’exemple suivant, la SystemTime classe a une disposition de membre séquentielle et peut être passée à la fonction API GetSystemTime Windows.

<StructLayout(LayoutKind.Sequential)> Public Class SystemTime
   Public wYear As System.UInt16
   Public wMonth As System.UInt16
   Public wDayOfWeek As System.UInt16
   Public wDay As System.UInt16
   Public wHour As System.UInt16
   Public wMinute As System.UInt16
   Public wSecond As System.UInt16
   Public wMilliseconds As System.UInt16
End Class

[StructLayout(LayoutKind.Sequential)]
   public class SystemTime {
   public ushort wYear;
   public ushort wMonth;
   public ushort wDayOfWeek;
   public ushort wDay;
   public ushort wHour;
   public ushort wMinute;
   public ushort wSecond;
   public ushort wMilliseconds;
}

La GetSystemTime fonction est définie comme suit :

void GetSystemTime(SYSTEMTIME* SystemTime);

La définition d'appel pour la plateforme équivalente de GetSystemTime est la suivante :

Friend Class NativeMethods
    Friend Declare Auto Sub GetSystemTime Lib "Kernel32.dll" (
        ByVal sysTime As SystemTime)
End Class

internal static class NativeMethods
{
   [DllImport("Kernel32.dll", CharSet = CharSet.Auto)]
   internal static extern void GetSystemTime(SystemTime st);
}

Notez que l’argument SystemTime n’est pas typé comme argument de référence, car SystemTime il s’agit d’une classe, et non d’un type valeur. Contrairement aux types valeur, les classes sont toujours passées par référence.

L’exemple de code suivant montre une classe différente Point qui a une méthode appelée SetXY. Étant donné que le type a une disposition séquentielle, il peut être passé à du code non géré et converti en tant que structure. Toutefois, le SetXY membre n’est pas appelable à partir du code non managé, même si l’objet est passé par référence.

<StructLayout(LayoutKind.Sequential)> Public Class Point
   Private x, y As Integer
   Public Sub SetXY(x As Integer, y As Integer)
      Me.x = x
      Me.y = y
   End Sub
End Class

[StructLayout(LayoutKind.Sequential)]
public class Point {
   int x, y;
   public void SetXY(int x, int y){
      this.x = x;
      this.y = y;
   }
}

Types valeur utilisés dans COM Interop

Les types mis en forme peuvent également être passés aux appels de méthode d'interopérabilité COM. En fait, lorsqu’ils sont exportés vers une bibliothèque de types, les types valeur sont automatiquement convertis en structures. Comme l’illustre l’exemple suivant, le Point type valeur devient une définition de type (typedef) avec le nom Point. Toutes les références au Point type valeur ailleurs dans la bibliothèque de types sont remplacées par le Point typedef.

Représentation de bibliothèque de types

typedef struct tagPoint {
   int x;
   int y;
} Point;
interface _Graphics {
   …
   HRESULT SetPoint ([in] Point p)
   HRESULT SetPointRef ([in,out] Point *p)
   HRESULT GetPoint ([out,retval] Point *p)
}

Les règles utilisées pour marshaler des valeurs et des références aux appels de code non managé sont également utilisées lors du marshaling via les interfaces COM. Par exemple, quand une instance du type valeur Point est passée de .NET Framework à COM, le Point est passé par valeur. Si le type valeur Point est passé par référence, un pointeur vers un Point est passé sur la pile. Le marshaleur d’interopérabilité ne prend pas en charge les niveaux élevés d’indirection (Point **) dans les deux directions.

Remarque

Les structures dont la LayoutKind valeur d’énumération est définie Explicit ne peuvent pas être utilisées dans l’interopérabilité COM, car la bibliothèque de types exportée ne peut pas exprimer une disposition explicite.

Types de valeurs système

L'espace de noms System contient plusieurs types valeur qui représentent la forme encapsulée des types primitifs de l'environnement d'exécution. Par exemple, la structure de type valeur System.Int32 représente la forme emboîtée de ELEMENT_TYPE_I4. Au lieu de marshaler ces types en tant que structures, comme le sont les autres types mis en forme, vous les marshalez de la même façon que les types primitifs qu’ils encadrent. System.Int32 est donc marshalé comme ELEMENT_TYPE_I4 au lieu d’une structure contenant un seul membre de type long. Le tableau suivant contient une liste des types valeur dans l'espace de noms System qui sont des représentations encapsulées de types primitifs.

Type de valeur système Type d’élément
System.Boolean ELEMENT_TYPE_BOOLEAN
System.SByte ELEMENT_TYPE_I1
System.Byte ELEMENT_TYPE_UI1
System.Char ELEMENT_TYPE_CHAR
System.Int16 ELEMENT_TYPE_I2
System.UInt16 ELEMENT_TYPE_U2
System.Int32 ELEMENT_TYPE_I4
System.UInt32 ELEMENT_TYPE_U4
System.Int64 ELEMENT_TYPE_I8
System.UInt64 ELEMENT_TYPE_U8
System.Single ELEMENT_TYPE_R4
System.Double ELEMENT_TYPE_R8
System.String ELEMENT_TYPE_STRING
System.IntPtr ELEMENT_TYPE_I
System.UIntPtr ELEMENT_TYPE_U

Certains autres types de valeur dans l'espace de noms System sont gérés différemment. Comme le code non managé a déjà des formats bien établis pour ces types, le marshaleur a des règles spéciales pour les marshaler. Le tableau suivant répertorie les types de valeurs spéciales dans l'espace de noms System, ainsi que le type non managé auquel ils sont marshallés.

Type de valeur système Type de l'IDL
System.DateTime DATE
System.Decimal DÉCIMAL
System.Guid GUID
System.Drawing.Color OLE_COLOR

Le code suivant montre la définition des types non managés DATE, GUID, DECIMAL et OLE_COLOR dans la bibliothèque de types Stdole2.

Représentation de bibliothèque de types

typedef double DATE;
typedef DWORD OLE_COLOR;

typedef struct tagDEC {
    USHORT    wReserved;
    BYTE      scale;
    BYTE      sign;
    ULONG     Hi32;
    ULONGLONG Lo64;
} DECIMAL;

typedef struct tagGUID {
    DWORD Data1;
    WORD  Data2;
    WORD  Data3;
    BYTE  Data4[ 8 ];
} GUID;

Le code suivant montre les définitions correspondantes dans l’interface managée IValueTypes .

Public Interface IValueTypes
   Sub M1(d As System.DateTime)
   Sub M2(d As System.Guid)
   Sub M3(d As System.Decimal)
   Sub M4(d As System.Drawing.Color)
End Interface

public interface IValueTypes {
   void M1(System.DateTime d);
   void M2(System.Guid d);
   void M3(System.Decimal d);
   void M4(System.Drawing.Color d);
}

Représentation de bibliothèque de types

[…]
interface IValueTypes : IDispatch {
   HRESULT M1([in] DATE d);
   HRESULT M2([in] GUID d);
   HRESULT M3([in] DECIMAL d);
   HRESULT M4([in] OLE_COLOR d);
};

Voir aussi

  • Last updated on