Partager via


Spécification CLS (Common Language Specification)

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

Tableaux1

   

   

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.

Voir aussi

Concepts

Vue d'ensemble de l'interopérabilité des langages

Autres ressources

Interopérabilité interlangage