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.
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.
If a type (class or value type) is given its own code, it cannot be referenced in signatures other than by this code. | |