Considérations de design pour l'interopérabilité

Cette vue d'ensemble explique les différences entre les modèles de programmation managés et non managés. Pour obtenir des recommandations et des stratégies d'interopérabilité au moment du design, consultez Génération de composants COM pour l'interopérabilité et Génération de composants .NET Framework pour l'interopérabilité.

Tous les appels effectués entre du code managé et non managé doivent négocier les exigences imposées par les modèles de programmation respectifs. Les modèles de programmation managée et non managée sont différents à bien des égards. Le tableau suivant indique les caractéristiques spécifiques de chaque modèle.

Caractéristique	Modèle non managé	Modèle managé	Détails
Modèle de codage	Lié à l'interface	Lié aux objets	Les objets non managés communiquent toujours par interfaces ; les objets managés et les classes peuvent passer des données directement sans implémenter d'interfaces. Par défaut, COM Interop génère une interface de classe pour exposer à COM des fonctionnalités managées via une interface lorsque l'objet ou la classe n'en implémente aucune.
Identité	GUID	Noms forts	Les GUID identifient un type non managé spécifique et ne fournissent aucune information d'emplacement pour ce type. Les noms forts correspondent à un nom d'assembly unique s'ajoutant à un nom de type. Comme le nom de l'assembly identifie le type de manière unique, vous pouvez réutiliser un nom de type entre plusieurs assemblys. Un assembly introduit également des informations de clé d'éditeur, de version, et d'emplacement vers un type managé. Les services d'interopérabilité génèrent des GUID et possèdent des noms forts selon les besoins.
Mécanisme de gestion des erreurs	HRESULTs	Exceptions	Les méthodes COM retournent habituellement un HRESULT, indiquant que l'appel a abouti ou échoué. Le code managé incorpore des exceptions. Par défaut, COM Interop mappe des exceptions managées aux valeurs HRESULT d'échec.
Structure POD (Plain Old Data Structure)	Structure	Structure managée dérivée de l'objet	L'appel de code non managé ne peut pas être utilisé pour retourner des structures ou des classes par valeur si celles-ci contiennent un constructeur. Généralement, les types définis par l'utilisateur qui contiennent des éléments non PODS doivent être retournés par référence. Les structures PODS sont des structures de données qui contiennent uniquement des collections passives de valeurs de champ, comme défini par la norme ISO/CEI 14882, "Programming Languages — C++". Elles ne contiennent pas de constructeurs, d'opérateurs d'assignation de copie, de destructeurs ni de membres de données non statiques qui ne sont pas eux-mêmes des structures PODS.
Compatibilité de type	Standard binaire	Standard type	Les types diffèrent entre du code managé et non managé, ainsi qu'entre les langages.
Définition de types	Bibliothèque de types	Métadonnées	Si vous êtes habitué à travailler avec des bibliothèques de types, vous savez qu'elles contiennent uniquement des types publics. En outre, une bibliothèque de types est facultative. Dans le modèle de programmation managée, les informations de type sont obligatoires pour tous les types. Les services d'interopérabilité fournissent des outils qui convertissent les bibliothèques de types en métadonnées dans les assemblys et les métadonnées en bibliothèques de types.
Sécurité de type	Pas de type sécurisé	Facultativement sécurisé	Les compilateurs non managés ne fournissent aucun type qui vérifie les types de pointeur, ce qui expose le code à des activités potentiellement préjudiciables. En général, le code managé nécessite un degré de confiance plus élevé. Les programmeurs peuvent continuer à utiliser des pointeurs dans du code managé, bien que le code fasse l'objet de restrictions en raison de son comportement non sécurisé. Les services d'interopérabilité empêchent le code managé non fiable d'accéder au code non managé.
Versioning	Immuable	Résistant	Les interfaces COM sont immuables. Si vous changez une interface, vous devez lui attribuer un nouveau GUID. Les types managés peuvent évoluer tout en conservant le même nom.

Certaines caractéristiques de modèle de programmation possèdent des entités associées que vous pouvez voir, telles que les bibliothèques de types et les métadonnées. Vous pouvez en passer certaines comme des arguments, tels que les GUID (Globally Unique Identifier) et les noms forts. D'autres caractéristiques sont plus conceptuelles ; vous envisagerez sans aucun doute leur impact sur le design de votre application, mais vous ne rencontrerez pas de correspondance directe entre les modèles managés et non managés pour ces caractéristiques.

Rubriques connexes

Titre	Description
Génération de composants COM pour l'interopérabilité	Décrit les stratégies d'interopérabilité au moment du design pour des composants COM.
Génération de composants .NET Framework pour l'interopérabilité	Décrit les stratégies d'interopérabilité au moment du design pour des composants .NET Framework.
Interopération avec du code non managé	Décrit comment utiliser COM Interop et l'appel de plateforme.
Interopérabilité COM avancée	Décrit les concepts COM Interop et les règles de conversion.
Marshaling d'interopérabilité	Décrit le service marshaling d'interopérabilité, sa relation avec le marshaling COM et son rôle dans les communications distantes.