Representing Classes in Signatures

Representing Classes in Signatures

The classes and value types in general are represented in signatures by their TypeDef or TypeRef tokens, preceded by E_T_CLASS or E_T_VALUETYPE, respectively, as shown in Table 7-8.

Table 7-8  Representation of CLASS and VALUETYPE

Code

Constant Name

.NET Framework Type Name

ILAsm Notation

Comments

0x11

VALUETYPE

valuetype <class_ref>

Value type

0x12

CLASS

class <class_ref>

Class or interface, except [mscorlib]System.Object and [mscorlib]System.String

0x0E

STRING

String

string

[mscorlib]System.String class

0x1C

OBJECT

Object

object

[mscorlib]System.Object class

As you can see in Table 7-8, two classes, String and Object, are assigned their own codes and hence should have been listed along with primitive data types in Table 7-1, if it were not for their class nature. This is important: if a type (class or value type) is given its own code, it cannot be referenced in signatures other than by this code. In other words, the class [mscorlib]System.Object must appear in signatures as E_T_OBJECT and never as E_T_CLASS<token_of_Object>, and the value type [mscorlib]System.Int32 must appear in signatures as E_T_I4 and never as E_T_VALUETYPE<token_of_Int32>.

The JIT (just-in-time) compiler does not accept “long forms” of type encoding for types that have dedicated type codes assigned to them, and run-time signature validation procedures reject such signatures.

important

If a type (class or value type) is given its own code, it cannot be referenced in signatures other than by this code.



Inside Microsoft. NET IL Assembler
Inside Microsoft .NET IL Assembler
ISBN: 0735615470
EAN: 2147483647
Year: 2005
Pages: 147
Authors: SERGE LIDIN

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net