NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Collected CLS Rules

The complete set of CLS rules are collected here for reference. Recall that these rules apply only to “externally visible” items – types that are visible outside of their own assembly and members of those types that have public, family, or family-or-assembly accessibility. Furthermore, items may be explicitly marked as CLS-compliant or not using the System.CLSCompilantAttribute.

  1. Boxed value types are not part of the CLS. Instead, use System.Object, System.ValueType or System.Enum, as appropriate.
  2. Languages must follow Annex 7 of Technical Report 15 of the Unicode Standard 3.0 (ISBN 0-201-61633-5) governing canonicalization of identifiers, available on-line at http://www.unicode.org/unicode/reports/tr15/tr15-18.html. While the CLS allows the use of case-insensitive comparison (canonicalization KC), identifiers must be persisted in their original case (canonicalization C) so that case sensitive comparisons work as expected.
  3. Languages must provide an escape mechanism to reference identifiers that happen to be keywords in their own language. In addition, extender languages must provide a mechanism for defining and overriding virtual methods with names that are keywords in their language. In order to override an inherited definition the VOS requires the precise encoding of the original declaration be used.
  4. All names introduced in a scope shall be distinct independent of kind. That is, while the VOS allows a single type to use the same name for a method and a field, the CLS does not.
  5. Fields and nested types must be distinct by identifier comparison alone, even though the VOS allows distinct signatures to be distinguished. Methods, properties, and events that have the same name (by identifier comparison) must differ by more than just the return type (although there is a special exception discussed in Conversion Operators).
  6. The underlying type of an enum must be a built-in CLS integer type.
  7. There are two distinct kinds of enums, indicated by the presence or absence of the System.FlagsAttribute custom attribute. One represents named integer values, the other named bit flags that can be combined together to generate an unnamed value. While languages are encouraged to distinguish these, they need not do so.
  8. Literal static fields of an enum must have the type of the enum itself.
  9. Accessibility must not be changed when overriding inherited methods, except when overriding a method inherited from a different assembly with accessibility family or assembly. In this case the override must have accessibility family.
  10. All types appearing in a signature must be CLS-compliant.
  11. The visibility and accessibility of types and members must be such that types in the signature of any member must be visible and accessible whenever the member itself is visible and accessible. For example, a public method that is visible outside its assembly must not have an argument whose type is visible only within the assembly.
  12. Typed references are not CLS-compliant.
  13. The varargs constraint is not part of the CLS, and the only calling convention supported by the CLS is the standard managed calling convention.
  14. Arrays elements must have a CLS-compliant type, a fixed number of dimensions, and all dimensions of the array must have zero lower bounds. While the abstract type System.Array is considered CLS-compliant it does have types that inherit from it but are not CLS-compliant.
  15. Pointer types are not CLS-compliant.
  16. CLS-compliant tools must deal with the fact that a single type may implement two interfaces and those interfaces may each require the definition of a method of the same name and signature. These methods are considered distinct and need not have the same implementation.
  17. CLS-compliant interfaces do not define static or instance methods, nor do they define fields.
  18. CLS-compliant classes, boxed value types, and interfaces must not require the implementation of non-CLS-compliant interfaces.
  19. An object constructor must call a base class constructor before any access occurs to inherited instance data.
  20. An object constructor shall not be called except as part of the creation of an object, and no object should be initialized twice.
  21. A CLS-compliant class must inherit from a CLS-compliant class. System.Object is CLS-compliant.
  22. The CLS restricts boxed value types to inherit directly from System.ValueType unless they are enumerations, in which case they must inherit directly from System.Enum.
  23. The methods that implement the getter and setter methods of a property must be marked mdSpecialName in the metadata.
  24. The accessibility of the property and of its accessors must be identical.
  25. The property and its accessors must all be static, all be virtual, or all be instance.
  26. The type of the property must match the return type of the getter and the last argument of the setter. The types of the parameters of the property must match the types of the parameters to the getter and the types of all but the final parameter of the setter. All of these types must be CLS-compliant, and must not be managed pointers (i.e. cannot be passed by reference).
  27. Properties must adhere to a specific naming pattern. See Naming Patterns.
  28. The methods that implement the event must be marked mdSpecialName in the metadata.
  29. The add and remove methods for an event must both either be present or absent.
  30. Events must adhere to a specific naming pattern. See Naming Patterns.
  31. CLS-compliant types must not use explicitlayout.
  32. CLS-compliant tools are only required to deal with a subset of the encodings of custom attributes. The only types that can appear in these encodings are: System.Type, System.String, System.Char, System.Boolean, System.Byte, System.Int16, System.Int32, System.Int64, System.Single, System.Double, and any enumeration type based on a CLS-compliant base type.
  33. CLS-compliant tools shall not generate publicly visible required modifiers, and shall ignore optional modifiers they do not understand. They need not emit either kind of modifier, although they must be able to copy both kinds of modifiers should they exist in metadata that they import.
  34. Global static fields and methods are not CLS-compliant.
  35. Types whose CLS-compliance differs from that of the assembly in which they are defined must be marked with the System.CLSCompliantAttribute. Similarly, members whose CLS-compliance differs from that of their class must also be so marked.
  36. Fields and events may not be overloaded within a given class.
  37. Properties, instance methods, and virtual methods may be overloaded based only on the types of their parameters, except the methods named op_Implicit and op_Explicit which may also be overloaded based on their return type.
  38. If either op_Implicit or op_Explicit is overloaded on its return type, an alternate means of providing the coercion must be provided.
  39. The functionality provided by op_Implicit or op_Explicit should also be provided through the FromXxx and ToXxx naming pattern.
  40. Exception objects must derive from System.Exception