Qu'est-ce que la spécification CLS (Common Language Specification) ?
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 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 bibliothèque de classes .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 du .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 JIT.
Le tableau ci-dessous 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, qui se trouve dans le répertoire Tool Developers Guide figurant dans le Kit de développement .NET Framework SDK de Microsoft.
| Fonctionnalité | Application | 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 à l'adresse www.unicode.org/unicode/reports/tr15/tr15-18.html.
Pour que deux identificateurs soient considérés comme étant distincts, ils ne doivent pas 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 dans Bibliothèque de classes .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 à la place 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 type | ||
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 ne peuvent être surchargées qu'en fonction du nombre et des types de leurs paramètres. La surcharge de l'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 de l'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 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 dans 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. |
Accessibilité d'accesseur |
Toutes | L'accessibilité de la propriété et de ses accesseurs doit être identique. |
Modificateurs |
Toutes | La propriété et ses accesseurs doivent tous être static, virtual ou instance. |
Noms d'accesseur |
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 de pointeur | ||
Pointeurs |
Toutes | Les types de pointeur et les types de 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 static, 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 nulle. |
| É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. |
Voir aussi
Interopérabilité interlangage | Vue d'ensemble de l'interopérabilité des langages