An interface definition defines an interface type. An interface type is a named group of methods, locations and other contracts that must be implemented by any object type that supports the interface contract of the same name. An interface definition is always an incomplete description of a value, and as such can never define a class type or an exact type, nor can it be an object type.
Zero or more object types can support an interface type, and only object types can support an interface type. An interface type can require that objects that support it must also support other (specified) interface types. An object type that supports the named interface contract must provide a complete implementation of the methods, locations, and other contracts specified (but not implemented by) the interface type. Hence, a value of an object type is also a value of all of the interface types the object type supports. Support for an interface contract is declared, never inferred, i.e. the existence of implementations of the methods, locations, and other contracts required by the interface type does not imply support of the interface contract.
CLS Rule 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.
CLS (consumer): must provide some means for accessing all methods of all interfaces supported by a type
CLS (extender): must provide a mechanism for providing independent implementations for all methods of all interfaces supported by a type.
CLS (framework): must assume that implementations of methods of the same name and signature on different interfaces are independent.
Interfaces types are necessarily incomplete since they say nothing about the representation of the values of the interface type. For this reason, an interface type definition cannot provide field definitions for values of the interface type (i.e. instance fields), although it can declare static fields (see Static Fields and Static Methods).
Similarly, an interface type definition cannot provide implementations for any methods on the values of the types. However, an interface type definition can and usually does define method contracts (method name and method signature) that must be implemented by supporting types. An interface type definition can define and implement static methods (see Static Fields and Static Methods) since static methods are associated with the interface type itself rather than with any value of the type.
Note: In V1, interfaces can have static or virtual methods, but not instance methods.
CLS Rule 17: CLS-compliant interfaces do not define static or instance methods, nor do they define fields.
CLS (consumer): need not accept interfaces that violate these rules.
CLS (extender): need not provide syntax to author interfaces that violate these rules.
CLS (framework): must not externally expose interfaces that violate these rules. Where static methods, instance methods, or fields are required a separate class may be defined that provides them.
Interface types can also define event and property contracts that must be implemented by object types that support the interface. Since event and property contracts reduce to sets of method contracts (Contracts), the above rules for method definitions apply. For more information, see Event Definitions and Property Definitions.
Interface type definitions can specify other interface contracts that implementations of the interface type are required to support. See Interface Type Inheritance for specifics.
An interface type is given a visibility attribute, as described in section Visibility, Accessibility, and Security, that controls from where the interface type can be referenced. An interface type definition is separate from any object type definition that supports the interface type. Hence, it is possible, and often desirable, to have a different visibility for the interface type and the implementing object type. However, since accessibility attributes are relative to the implementing type rather than the interface itself, all members of an interface must have public accessibility, and no security permissions may be attached to members or to the interface itself.