MSIL Programming: Part 2

• MSIL Programming: Part 1

Abstract

The primary goal of this article is to exhibit the mechanism of defining (syntax and semantics) the entire typical Object-Oriented Programming “terms” like a namespace, interface, fields, class, and so on, in particular, CIL metadata programming perspectives without having the IntelliSense support because we are practicing IL code authoring using common editors that unfortunately, don't leverage such features. IL coding enables the developers to directly implement the typical functionality of the C# language using its opcode instructions, for instance creating and consuming DLL files or invoking methods of an unmanaged DLL into IL code without relying on Visual Studio IDE. Such inner understandings of IL coding could be beneficial, especially for code optimization, debugging, and reverse engineering, in terms of malicious code detection and subverting essential security mechanisms.

Field Metadata

Fields are data locations for diverse .NET types, for instance numeric, character, and decimal. A field can be defined using a .field directive, which has three types of information- name, signature, and access modifier (flag). Moreover, fields in the .NET framework could be categorized as a value type or reference type; hence, it is also important to recognize the owner of the field such as TypeRef, TypeDef, or ModuleRef. The field flags determine the accessibility scope of the field inside or outside the assembly. In fact, a flag does categorize further as accessibility (public, private), contract (static, initonly, literal), and reserved (marshal, rtspecialname). The type indicates the kind of data such as strings, characters, or numeric that will be stored at a specific location. The fields could be either global (inside class type) or local (inside function scope). Hence, the following code snippet is showing the data fields that are defined in the class-level scope. Syntax 1: Fields declaration in IL code: In the case of class-level data initialization, the default value can be directly assigned to the variable as in the following: The data fields that are defined inside the method body are considered to be “local data” and defined using a .locals directive. Here, we are defining a local integer type value as in the following: Hence the following code demonstrates some common operation by specifying both local variables and global variables (outside the method) as in the following. Listing 1: Fields declaration in IL code

Properties Metadata

Properties enable strict control of access to the internal state of an object. It behaves like a public field and the notation to access property is the same as a public field on the instance. A property is a shorthand notation used to read and write fields. The .property directive is employed to define a property by use of the related .get and .set directives as in the following. Syntax 2: Properties declaration in IL code: Listing 2: Properties declaration in IL code

Namespace

A namespace is a consortium of related .NET types, such as class, interface, and so on contained in an assembly, particularly employed to fully qualify a class name. Moreover, a single assembly can have more than one namespace definition. A namespace in IL coding is declared using the .namespace directive in the following way. Syntax 3: Namespace declaration: Namespace could be declared nested like class type since one namespace can contain the definition of another and so on. The important point to remember is that namespaces are neither considered to be metadata nor referenced by IL tokens. Examine the following metadata where there is no entry of metadata and the token pertains to the namespace:

Class Metadata

The Class type in IL code is defined using a .class directive and implicitly obtains the entry of the .NET System.Object base class entry, as well as class, should be specified by its full name, even if it resides in the same assembly. Syntax 4: Class declaration: As we know, the C# code controls the visibility of fields, methods, classes, and property types using various keywords like public, private, abstract, sealed, and so on. Hence, IL code has such keywords that are counterparts to control the availability of types inside or outside the assembly. The following table gives a brief description of these IL code attributes. Table 1: Visibility attributes IL code

Constructor Metadata

A constructor invokes class fields and is defined using .ctor and .cctor directives in the IL code, where .ctor represents an instance-level constructor while .cctor epitomizes static-level constructors. Moreover, it is always implicitly treated as void indeed, due to not returning a value. Here, the following code shows a default class constructor. Syntax 5: Parameterless Constructor declaration: In the previous code, it is mandatory to prefix the specialname and rtspecialname attributes that uniquely identify each constructor definition in the IL code. In case of initializing the class fields using a constructor, for example, invoking an integer variable, the specification should be as in the following: Syntax 6: Parameter Constructor declaration: Here, we are defining a class constructor that handles strings as a parameter and invoked later during class instantiation as in the following: Listing 3: Constructor declaration in IL code:

Interface Metadata

An interface is similar to a classic COM interface, defined as a descriptor of properties and methods of a class type. Moreover, an interface can't offer the implementation of these exposed items except the static members; in fact, an interface can only implement another interface. An interface is neither derived from another type like class nor can't be any other type derived from it. The interface shouldn't be sealed and methods defined in an interface must be marked as virtual. Interface types are defined using the .class directive in IL code as in the following: Syntax 7: Interface declaration: