A property definition defines a named value and the methods that access the value. A property definition defines the accessing contracts on that value. Hence, the property definition specifies which accessing methods exist and their respective method contracts. An implementation of a type that declares support for a property contract must implement the accessing methods required by the property contract. The implementation of the accessing methods defines how the value is retrieved and stored.
A property definition is always part of either an interface definition or a class definition. The name and value of a property definition is scoped to the object type or the interface type that includes the property definition. While all of the attributes of a member may be applied to a property (accessibility, static, etc.) these are not enforced by the VOS. Instead, the VOS requires that the method contracts that comprise the property must match the method implementations, as with any other method contract. There are no IL instructions associated with properties, just metadata.
By convention, properties define a getter method (for accessing the current value of the property) and optionally a setter method (for modifying the current value of the property). The VOS places no restrictions on the set of methods associated with a property, their names, or their usage.
CLS Rule 23: The methods that implement the getter and setter methods of a property must be marked mdSpecialName in the metadata.
CLS Rule 24: The accessibility of the property and of its accessors must be identical.
CLS Rule 25: The property and its accessors must all be static, all be virtual, or all be instance.
CLS Rule 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).
CLS Rule 27: Properties must adhere to a specific naming pattern. See Naming Patterns.
CLS (consumer): Must ignore the mdSpecialName bit in appropriate name comparisons and must adhere to identifier rules. Otherwise, no direct support other than the usual access to the methods which define the property.
CLS (extender): Must ignore the mdSpecialName bit in appropriate name comparisons and must adhere to identifier rules. Otherwise, no direct support other than the usual access to the methods which define the property. In particular, an extender need not be able to define properties.
CLS (framework): Must design understanding that not all CLS languages will access the property using special syntax.