Spécification CLS (Common Language Specification)

Article
08/21/2008

Mise à jour : novembre 2007

Pour interagir entièrement avec d'autres objets quel que soit le langage dans lequel ils ont été implémentés, les objets ne doivent exposer aux appelants que les fonctionnalités qui sont communes à tous les langages avec lesquels ils doivent fonctionner. Pour cette raison, un ensemble de fonctionnalités de langage appelé spécification CLS (Common Language Specification), qui comprend les fonctionnalités de langage de base nécessaires à de nombreuses applications, a été défini. Les règles CLS définissent un sous-ensemble du Système de type commun; en d'autres termes, toutes les règles qui s'appliquent au système de type commun (CTS, Common Type System) s'appliquent à la spécification CLS, sauf dans les cas où des règles plus strictes sont définies dans la spécification CLS. La spécification CLS permet d'optimiser et d'assurer l'interopérabilité des langages en définissant un ensemble de fonctionnalités sur lequel les développeurs peuvent compter dans de nombreux langages. La spécification CLS établit également des exigences de conformité CLS ; elles vous permettent de déterminer si votre code managé est conforme à la spécification CLS et dans quelle mesure un outil donné prend en charge le développement du code managé qui utilise des fonctionnalités CLS.

Si votre composant n'utilise que des fonctionnalités CLS dans des interfaces API qu'il expose à un autre code (y compris des classes dérivées), le composant est assuré d'être accessible à partir d'un langage de programmation prenant en charge la spécification CLS. Les composants qui respectent les règles CLS et n'utilisent que les fonctionnalités incluses dans la spécification CLS sont considérés comme étant des composants conformes CLS.

La plupart des membres définis par types dans la Vue d'ensemble de la bibliothèque de classes du .NET Framework sont conformes CLS. Certains types figurant dans la bibliothèque de classes possèdent toutefois un ou plusieurs membres qui ne sont pas conformes CLS. Ces membres assurent la prise en charge de fonctionnalités de langage qui ne figurent pas dans la spécification CLS. Les types et les membres non conformes sont identifiés en tant que tels dans la documentation de référence et, dans tous les cas, une alternative conforme CLS existe. Pour plus d'informations sur les types figurant dans la bibliothèque de classes .NET Framework, consultez Référence de la bibliothèque de classes .NET Framework.

La spécification CLS a été conçue pour être suffisamment grande pour inclure les constructions de langage qui sont fréquemment utilisées par les développeurs, tout en étant suffisamment petite pour que la plupart des langages puissent la prendre en charge. De plus, toutes les constructions de langage qui empêchaient de vérifier rapidement la sécurité de type du code ont été exclues de la spécification CLS, de sorte que tous les langages conformes CLS puissent produire du code vérifiable s'ils choisissent de le faire. Pour plus d'informations sur la vérification de la sécurité de type, consultez Compilation du MSIL en code natif.

Le tableau suivant récapitule les fonctionnalités qui figurent dans la spécification CLS et indique si les fonctionnalités s'appliquent aux développeurs et aux compilateurs (Tous) ou uniquement aux compilateurs. Il est conçu pour être instructif, sans pour autant être exhaustif. Pour plus d'informations, consultez la spécification du Common Language Infrastructure, Partition I, disponible sur le site Web Microsoft Developer Network.

Fonctionnalité	S'applique à	Description
Général
Visibilité	Toutes	Les règles CLS s'appliquent aux éléments d'un type qui sont exposés en dehors de l'assembly de définition.
Membres globaux	Toutes	Les méthodes et les champs static globaux ne sont pas conformes CLS.
Attribution d'un nom
Caractères et casse	Toutes	Les compilateurs de langages conformes CLS doivent suivre les règles de l'Annexe 7 du Rapport technique 15 de la norme Unicode 3.0, qui régit l'ensemble des caractères pouvant commencer des identificateurs et y figurer. Cette norme est disponible sur le site Web du consortium Unicode. Pour que deux identificateurs soient considérés comme étant distincts, ils ne doivent pas ne différer que par leur casse.
Mots clés	Compilateurs	Les compilateurs de langages conformes CLS fournissent un mécanisme de référencement des identificateurs qui coïncident avec les mots clés. Les compilateurs de langages conformes CLS proposent un mécanisme de définition et de substitution des méthodes virtuelles portant des noms qui sont des mots clés dans le langage.
Unicité	Toutes	Tous les noms figurant dans une portée conforme CLS doivent être distincts, même si les noms sont destinés à deux types de membres différents, sauf dans les cas où les noms seraient identiques et résolus par la surcharge. Par exemple, la spécification CLS n'autorise pas un type seul à utiliser le même nom pour une méthode et un champ.
Signatures	Toutes	Tous les types de retour et de paramètre apparaissant dans une signature de type ou de membre doivent être conformes CLS.
Types
Types primitifs	Toutes	La bibliothèque de classes .NET Framework inclut des types qui correspondent aux types de données primitifs que les compilateurs utilisent. Les types suivants sont conformes CLS : Byte, Int16, Int32, Int64, Single, Double, Boolean, Char, Decimal, IntPtr et String. Pour plus d'informations sur ces types, consultez le tableau des types dans Vue d'ensemble de la bibliothèque de classes du .NET Framework.
Types boxed	Toutes	Les types valeur boxed (types valeur ayant été convertis en objets) ne figurent pas dans la spécification CLS. Utilisez plutôt System.Object, System.ValueType ou System.Enum, selon le cas.
Visibilité	Toutes	Les déclarations type et member ne doivent pas contenir de types qui soient moins visibles ou accessibles que le type ou le membre en cours de déclaration.
Méthodes d'interface	Compilateurs	Les compilateurs de langages conformes CLS doivent disposer d'une syntaxe dans le cas où un type seul implémenterait deux interfaces et que chacune de ces interfaces nécessiterait la définition d'une méthode portant le même nom et la même signature. Ces méthodes doivent être considérées comme étant distinctes et ne nécessitent pas la même implémentation.
Clôture	Toutes	Les membres individuels des interfaces et des classes abstraites conformes CLS doivent être définis comme étant conformes CLS.
Appel de constructeur	Toutes	Avant d'accéder à une donnée d'instance héritée, un constructeur doit appeler le constructeur d'une classe de base.
Références typées	Toutes	Les références typées ne sont pas conformes CLS. Une référence typée est une construction spéciale qui contient une référence à un objet et une référence à un type. Les références typées permettent au Common Language Runtime d'assurer la prise en charge de style C++ des méthodes qui possèdent un nombre d'arguments variable.
Membres de types
Surcharge	Toutes	Les propriétés, les méthodes et les constructeurs indexés peuvent être surchargés, tandis que les champs et les événements ne peuvent pas être surchargés. Les propriétés ne doivent pas être surchargées par type (c'est-à-dire par type de retour de leur méthode d'accesseur Get), mais elles peuvent être surchargées avec différents nombres ou types d'index. Les méthodes peuvent uniquement être surchargées en fonction du nombre et des types de leurs paramètres, et dans le cas des méthodes génériques, du nombre de leurs paramètres génériques. La surcharge d'opérateur ne figure pas dans la spécification CLS. La spécification CLS propose toutefois des indications sur l'attribution de noms utiles (tels que Add()) et sur la définition d'un bit dans des métadonnées. Les compilateurs qui choisissent de prendre en charge la surcharge d'opérateur sont censés suivre ces indications, mais ils ne sont pas tenus de le faire.
Unicité des membres surchargés	Toutes	Les champs et les types imbriqués doivent être distincts par comparaison d'identificateur seule. Les méthodes, les propriétés et les événements qui portent le même nom (par comparaison d'identificateur) ne doivent pas ne différer que par le type de retour.
Opérateurs de conversion	Toutes	Si op_Implicit ou op_Explicit est surchargé sur son type de retour, un autre moyen de conversion doit être proposé.
Méthodes
Accessibilité des méthodes substituées	Toutes	L'accessibilité ne doit pas être changée lors de la substitution de méthodes héritées, sauf en cas de substitution d'une méthode héritée d'un assembly différent par l'accessibilité FamilyOrAssembly. Dans ce cas, la substitution doit posséder l'accessibilité Family.
Listes d'arguments	Toutes	La seule convention d'appel prise en charge par la spécification CLS est la convention d'appel managée standard ; les listes d'arguments de longueur variable ne sont pas autorisées. Utilisez le mot clé ParamArray dans Microsoft Visual Basic et le mot clé params en C# pour la prise en charge d'un nombre d'arguments variable.
Propriétés
Métadonnées d'accesseur	Compilateurs	Les méthodes d'accesseur Get et Set qui implémentent les méthodes d'une propriété sont marquées de l'identificateur mdSpecialName dans les métadonnées.
Modificateurs	Toutes	La propriété et ses accesseurs doivent tous être static, virtual ou instance.
Noms d'accesseurs	Toutes	Les propriétés doivent respecter des modèles d'attribution de noms spécifiques. Pour une propriété appelée Name, la méthode d'accesseur Get, si elle est définie, sera appelée get_Name et la méthode d'accesseur Set, si elle est définie, sera appelée set_Name.
Type de retour et arguments	Toutes	Le type de la propriété correspond au type de retour de l'accesseur Get et au type du dernier argument de l'accesseur Set. Les types des paramètres de la propriété correspondent aux types des paramètres de l'accesseur Get et aux types de tous les paramètres de l'accesseur Set, sauf le dernier. Tous ces types doivent être conformes CLS et ne peuvent pas être des pointeurs managés ; ils ne doivent pas être passés par référence.
Événements
Méthodes d'événement	Toutes	Les méthodes permettant d'ajouter et de supprimer un événement doivent toutes les deux être présentes ou absentes.
Métadonnées des méthodes d'événement	Compilateurs	Les méthodes qui implémentent un événement doivent être marquées de l'identificateur mdSpecialName dans les métadonnées.
Accessibilité d'accesseur	Toutes	L'accessibilité des méthodes permettant d'ajouter, de supprimer et de déclencher un événement doit être identique.
Modificateurs	Toutes	Les méthodes permettant d'ajouter, de supprimer et de déclencher un événement doivent toutes être static, virtual ou instance.
Noms des méthodes d'événement	Toutes	Les événements doivent respecter des modèles d'attribution de noms spécifiques. Pour un événement nommé MyEvent, la méthode add, si elle est définie, sera nommée add_MyEvent, la méthode remove, si elle est définie, sera nommée remove_MyEvent et la méthode raise sera nommée raise_MyEvent.
Arguments	Toutes	Les méthodes permettant d'ajouter et de supprimer un événement doivent chacune disposer d'un paramètre dont le type définit le type de l'événement et ce type doit être dérivé de System.Delegate.
Types pointeur
Pointeurs	Toutes	Les types pointeur et les types pointeur fonction ne sont pas conformes CLS.
Interfaces
Signatures de membre	Toutes	Les interfaces conformes CLS ne doivent pas nécessiter de définition de méthodes non conformes CLS pour pouvoir les implémenter.
Modificateurs de membre	Toutes	Les interfaces conformes CLS ne peuvent pas définir de méthodes statiques, ni de champs. Elles peuvent définir des propriétés, des événements et des méthodes virtuelles.
Types référence
Appel de constructeur	Toutes	Pour les types référence, les constructeurs d'objet ne sont appelés que dans le cadre de la création d'un objet et les objets ne sont initialisés qu'une fois.
Types classe
Héritage	Toutes	Une classe conforme CLS doit hériter d'une classe conforme CLS (System.Object est conforme CLS).
Tableaux¹
Types d'élément	Toutes	Les éléments de tableau doivent être des types conformes CLS.
Dimensions	Toutes	Les tableaux doivent avoir un nombre de dimensions fixe supérieur à zéro.
Limites	Toutes	Toutes les dimensions d'un tableau doivent avoir une limite inférieure à zéro.
Énumérations
Type sous-jacent	Toutes	Le type sous-jacent d'une énumération doit être un type entier CLS intégré (Byte, Int16, Int32 ou Int64).
FlagsAttribute	Compilateurs	La présence de l'attribut personnalisé System.FlagsAttribute dans la définition d'une énumération indique que l'énumération doit être traitée en tant qu'ensemble de champs de bits (indicateurs) et l'absence de cet attribut indique que le type doit être affiché sous la forme d'un groupe de constantes énumérées. Il est recommandé que les langages utilisent soit FlagsAttribute soit une syntaxe spécifique au langage pour distinguer ces deux types d'énumérations.
Membres de champ	Toutes	Les champs static Literal d'une énumération doivent être du même type que le type de l'énumération elle-même.
Exceptions
Héritage	Toutes	Les objets qui sont levés doivent être de type System.Exception ou hériter de System.Exception.
Attributs personnalisés
Codages de valeurs	Compilateurs	Des compilateurs conformes CLS sont nécessaires pour traiter uniquement un sous-ensemble de codages d'attributs personnalisés (la représentation des attributs personnalisés dans les métadonnées). Les seuls types qui sont autorisés à figurer dans ces codages sont : System.Type, System.String, System.Char, System.Boolean, System.Byte, System.Int16, System.Int32, System.Int64, System.Single, System.Double et tout type d'énumération reposant sur un type entier de base conforme CLS.
Métadonnées
Conformité CLS	Toutes	Les types dont la conformité CLS diffère de celle de l'assembly dans lequel ils sont définis doivent être marqués de System.CLSCompliantAttribute. De la même façon, les membres dont la conformité CLS diffère de celle de leur type doivent également être marqués. Si un membre ou un type est marqué comme étant non conforme CLS, une alternative conforme CLS doit alors être proposée.
Génériques
Noms de types	Compilateurs	Le nom d'un type générique doit coder le nombre de paramètres de type déclarés sur le type. Le nom d'un type générique imbriqué doit coder le nombre de paramètres de type récemment introduits dans le type.
Types imbriqués	Compilateurs	Les types imbriqués doivent posséder autant de paramètres génériques que le type englobant. Les paramètres génériques d'un type imbriqué ont la même position que les paramètres génériques du type englobant correspondant.
Contraintes	Toutes	Un type générique doit déclarer des contraintes suffisantes afin de garantir que les contraintes du type générique répondent à toutes les contraintes du type ou des interfaces de base.
Types de contraintes	Toutes	Les types utilisés comme contraintes sur les paramètres génériques doivent eux-mêmes être conformes CLS.
Signatures de membre	Toutes	La visibilité et l'accessibilité des membres (y compris des types imbriqués) d'un type générique instancié doivent être définies dans l'instanciation spécifique plutôt que dans la déclaration générale du type générique.
Méthodes génériques	Toutes	À chaque méthode générique abstraite ou virtuelle doit correspondre une implémentation concrète (non abstraite) par défaut

1. Les tableaux en escalier, c'est-à-dire les tableaux de tableaux, sont conformes CLS. Dans la version 1.0 du .NET Framework, le compilateur C# signale par erreur qu'ils ne le sont pas.

Partager via

Spécification CLS (Common Language Specification)

Voir aussi

Concepts

Autres ressources

Ressources supplémentaires