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!

Member Signatures in Metadata

Every location — including fields, parameters, method return values, and properties — has a type, and a specification for its type is carried in metadata.

A value type describes values that are represented as a sequence of bits. A reference type describes values that are represented as the location of a sequence of bits. The NGWS runtime provides an explicit set of built-in types, each of which has a default runtime form as either a value type or a reference type. The metadata APIs may be used to declare additional types, and part of the type specification of a variable encodes the identity of the type as well as what form (value or reference) the type is to take at runtime.

Metadata tokens representing encoded types are passed to IL instructions that accept a type (newobj, newarray, ldtoken). See the IL Instruction Set specification.

Encoded types are also embedded in member signatures. To optimize runtime binding of field accesses and method invocations, the type and location signatures associated with fields and methods are encoded into member signatures in metadata. A member signature embodies all of the contract information that is used to decide whether a reference to a member succeeds or fails.

The unmanaged metadata APIs do not provide any support for building up signature encodings. Instead, a tool or compiler that uses the unmanaged APIs is expected to supply a properly encoded binary signature with each member declaration or member reference. Refer to the NGWS Runtime Type and Signature Encoding Specification for rules on the type and signature encoding. The managed Reflection Emit classes provide support for constructing signatures. See the Base Class Library Specification.