Chapter 4 other metadata tables

This chapter continues to describe the remaining tables that have not been involved. To this end, create a separate program to describe each different table. Finally, in the last chapter of the book, place them in a separate program, where each table is cross-referenced.

Table 4-1

The first program in this chapter uses the fields table. Enter the following code in the B. CS file and compile the file.

FieldsTable

B. CS

A. CS

Output

Instance variables are also called fields. The field table stores the index 4 in the valid table. Because the file spans two classes named ZZZ and YYY, they contain three fields, and the output shows three rows.

The field table consists of the following columns:

Table 4-2

The 1st column in the field table is the fieldattributes flag. Fieldattributes enumeration shows the string assigned to this number. The 2nd column in the table is related to the field name. It is the index of data included in the strings stream. The output clearly shows that the fields I and Vijay of the class ZZZ are put in front, followed by the field k of the class YYY IN THE namespace NNN. This order is extremely important and we will confirm it later.

The last field is the index in the Blob heap. It starts with the number of bytes 2, thus specifying that the field signature has two bytes. The 1st bytes in the method signature determine this call convention. Similarly, the 1st bytes in the signature are always 0x06, specifying that this is a field signature. This is basically a powerful check.

The value is followed by the signature byte. It is related to the field type. To determine this value, we introduce the function GetType, which returns the data type. Because of this function, the output will properly reflect the Data Type of the field. Section 22.1.15 describes the bitwise representation of each type. We will explain some of the most complex ones for emergency purposes.

Table 4-3

Let's return to the flag byte. Access modifier proptected-only allowed to be accessed by the derived class, is considered as the family in the Il world. Access modifier internal -- restrict access to the same assembly, which is considered to be an assembly in the Il world.

If C # uses a term similar to Il, it would be much easier together.

If we give up on this topic, we cannot expose the cross join between these tables to you. Therefore, we expand some necessary code for this program, while typedef details are absolutely necessary.

After calling the XYZ function, you also need to call the AAA function, like this: XYZ (); AAA ();

Put the following code before the GetType function.

A. CS

Output

The output of the above program shows the data included in the typedef table, where three rows in the table are displayed. Each row of the field table is owned by the rows in the typedef table. This is because the typedef table defines a class and its fields.

There is no indication of which type or class has fields in the field table. To determine these joins, check the typedef table. Row 1st indicates a global or pseudo class and can be ignored temporarily. The first line indicates the ZZZ class. The fieldlist column in this row points to the 1st rows in the field table.

Since the 1st rows in the field table represent variable I, it is logical to infer that variable I belongs to the class zzz.

Row 3rd of the typedef table indicates the YYY class in the namespace NNN. The value of the fieldlist field points to the 3rd rows in the field table. Therefore, we can safely consider that the first two rows are owned by the class zzz. However, fields from the first two rows belong to the class yyy. A row in the field table can only be owned by a row in the typedef table.

This forward pointer method helps us determine the owner of the field table. Using this method, fields in the class can be determined by reading the fieldlist column in the row. All rows in the field table belong to one type until we reach the given value in the fieldlist column of the next row. Note that the field table can contain 0 or more rows. This type includes all these rows.

This behavior is similar to parent-child or one-to-many relationship. The parent type can have multiple child fields. However, a child field can only have one parent type.

If two instance variables with the same name but in different classes exist, two independent rows will be created in the field table, each having a different typedef row. The same rule applies to methods.

MethodTable

Some rows are omitted here.

Because we focus mainly on the field table, we only display the name of each row in the method table. Since there are two classes in the file, we can see two constructors. The method name of. Ctor is displayed twice.

Both Row 2 and row 3 represent a constructor. Therefore, how do we determine which class each constructor belongs? Remember, when you see a constructor in the type, you should always start with the typedef table instead of the field table or method table. This method changes with our requirements for the methodref table. It has a typeref field to represent the data in the class-namespace.

Type ZZZ uses a field named methodlist, and its index is 1. 2nd classes, that is, YYY, with a methodlist of 3. Therefore, the first two rows of the method table belong to the class zzz, and the second row constitutes part of the class yyy.

ConstantTable

B. CS

A. CS

Output

Table 4-4

The constant table has the following columns:

Table 4-5

The constant table is located at the 11th location of the valid field, and its name indicates that it stores the constants created in the module.

A constant is also a field. Therefore, the corresponding item is appended to the field table. These tables, fields, and constants are displayed -- to allow you to involve them.

Table 4-6

The 1st fields in the table are related to the constant data type. It is a separate byte; therefore, the next byte-including the 0 value-is a padding byte. The trusted GetType function is used to display this type as a readable string.

The parent of the next field is the hasconst encoding index, where the first two tables are encoded-either a filed table, a Param table, or a property table.

Table 4-7

The remaining six digits store indexes. The two constants in this example are indexes in the field table.

Table 4-8

The field table stores the name and signature. The information provided by the signature field in the field table is the same as that provided by the type. However, the flags field shows a number instead of a string. Therefore, the constant name and flag come from the field table.

The last field stores the actual value assigned to the constant. The 1st bytes in this field is the length. If it is an integer, the following four bytes are obtained. However, if it is a string, the length of the string under unicode encoding is used-not ASCII encoding. The compiler uses blob heap to store constant values.

For this reason, constants are determined during compilation rather than during runtime.

Nested classesTable

B. CS

A. CS

Output

Table 4-10

In the B. CS file, class ZZZ outsourced class yyy. In the C # world, this is completely logical. This concept-outsourcing another class in one class-is called a "nested class" in terms of terms ". The YYY class contains a nested class named XXX in sequence-this is also allowed.

For each nested class, a record is added to the nested classes table, where the nested classes table is located at 41st index locations. By size, this is the smallest table we have encountered so far. It has only two indexes. Both indexes point to the typedef table, which defines a class.

Table 4-11

The typedef table contains four rows. Therefore, a total of four classes reside in the file. In addition to a pseudo class, there are three classes, which are obviously created in file B. CS. Thus, in the typedef table, nested classes are a class from its own perspective.

Because the nestedprivate bit is set to on, the flags field in the typedef table identifies this class as a nested class. Further, these three classes are described as derived from the system. Object Class.

Return to the nested classes table. The first field in the table is the name of the nested class. Therefore, Row 1 involves the 3rd indexes of the typedef table of the yyy type, and the 2nd rows point to the 4th rows of the XXX class.

The 2nd fields in the table are the enclosing field, which identifies the outsourcing class of the nested class. Because the YYY class is nested in the ZZZ class, this field shows the value of 2, which involves the 2nd rows in the typedef table. The 2nd class XXX is displayed as nested in the class YYY, or 3rd rows.

Therefore, the nested classes table is easy to understand because it only saves references to classes and its outsourcing classes. These are the indexes of the typedef table.

The nested class is defined in the lexical range of the outer class. However, when no nested class exists in the program module, the bit of the nested classes table is marked as off, eliminating all the traces to the table and the fact that it has existed.

The two fields of the nested class must reference valid rows in the typedef table. Otherwise, it is considered an error. In addition, the enclosingclass field cannot reference a valid row in the typeref table, and the latter displays a type reference. In addition, if the nested class shares the same value as the outsourcing class, a warning instead of an error will flow out.

No two rows can have the same value on nested fields. Because multiple Nested classes can be outsourced to a single class, this is the only situation in the outsourcing type. A single type may have countless Nested classes, but in turn it is not allowed.

ParamTable

B. CS

A. CS

Output

File B. CS now contains three functions: ABC without parameters, pqr with two parameters, and XYZ with three parameters. Parameters allocated to the method are stored in the param table. The index position of the param table in the valid field is 8. Since there are five parameters in total, the param table displays five rows.

Table 4-12

The param table has the following three fields:

Table 4-13

The 1st fields flagattributes describe the features assigned to function parameters.

Table 4-14

Therefore, a special function getparamattributes is provided. The only task of getparamattributes is to return a string, which depends on the bit that is switched to on in the flag bytes.

The first field is an serial number, and the second field is the parameter name.

Let's take a quick look at the method table. Row 2 and row 3 represent Methods ABC and pqr, respectively. They all point to the paramlist of Row 1. In this step, it looks deceptive because method ABC does not get any parameters, while method pqr gets two parameters. The constructor in Row 1 does not obtain any parameters. However, it points to row 1st in the parameter list.

However, as we learned in the previous chapter, we must check the 2nd bytes of the Blob heap to determine the actual number of parameters to be passed by this function. Neither the constructor nor the ABC function obtains any parameters, because the value specified in the 2nd bytes is 0.

Table 4-15

The pqr method obtains two parameters. Therefore, in the param table, the function parameters appear after the first row. The sequence number identifies the order of parameters. This is why the value of 1st parameter I is 1, the value of 2nd Parameter Z is 2, and so on.

The 4th rows in the method table represent the method XYZ. The number of parameters in the Blob heap is displayed as 3, which involves 3rd rows in the param table. Row 3rd in the param table has a parameter named J, whose serial number is 1. The number of the next row of parameter k is 2.

Therefore, the sequence number provides the sequence of parameters. It starts at 1, and will be reset to 1 for every new method since then. The proper method is that the Blob field in the method table is read first, which determines the number and type of parameters. Then, depending on the value of the Params field, the corresponding row in the param table is accessed. The param table provides the parameter names, features, and order in the param list. Then, the next group of rows is obtained from the param table based on the number of parameters in the Blob field.

The number of parameters can be re-determined by checking the value in the serial number. For unknown reasons, the feature bit is not precisely set.

The in parameter is default in C. When a function is called to modify the parameter value, the out parameter is used. Ref is a variant in C. It is considered a variant of in. Therefore, it does not display the out feature. However, according to our explanation, ref is the variant of out. You may blame us for this misunderstanding and lack foresight. Another possibility is that the C # compiler will take a break.

Conceptually, each row in the method table has a row in the param table, and the only exception is Row 1. A row cannot have two owners in the method table. Therefore, if two functions ABC and pqr have only one parameter, namely int I, there are two unique rows in the param table. This is not considered to be wrong at all, because repeated rows are acceptable.

The serial number can be 0, indicating the return type of the owner's method. Sequence numbers are arranged according to the increasing sequence values. Result. You can ignore the sequence number, which is completely valid.

Parameters in the. NET world cannot have default values. Therefore, the hasdefault flag will always be 0.

PropertiesTable

B. CS

A. CS

Output

As usual, let's start with file B. CS. In class zzz, there are two attributes, namely AA and BB. In Class YYY, there is a separate attribute CC.

In A. CS, the details of the propertiesmap table are initially displayed before the values in the property table are displayed. This table is located at the 21st position in the valid table.

The value of the tableoffset variable is always stored in the variable old instead of in the variable new1.

The propertiesmap table has the following two rows:

Table 4-17

The first field is called the parent, which is an index in the typedef table. Because there are two classes that contain attributes, we can see two rows. The fifth row points to the first row of zzz in the typedef table. The parent field of row 2nd points to row 3rd of yyy in the typedef table.

The 2nd rows in the propertymap table are indexes in the property table. This table is shown as follows:

The property table has the following columns:

Table 4-18

Table 4-19

The property table is 23rd bits in the valid table. The 1st fields in the table are a propertyattributes enumeration. The first field is the attribute name. The 3rd fields are a series of bytes in blob.

Let's return to the propertymap table. The index of the first row of the class ZZZ in the property table is 1. However, the index of the second row is 3. Because the value of 2 does not exist, this indicates that the first two rows of the property table are owned by typedef [2] -- that is, the class zzz.

Each attribute includes a row in the property table. Thus, a link is typedef-propertymap-property. Now, let's check the rows in the method table.

MethodTable

Some output is omitted below

This table is modified by nine functions. Hello, please wait! We only want three functions, namely the main function and the constructor of classes ZZZ and yyy. Now, we have gradually reached a critical moment. For the emergence of each attribute AA, two methods are created: one is set_aa used as the write accesser, and the other is get_aa used as the read accesser.

Because there are three attributes in the file, a total of six functions are created. Then, six rows are added to the method table.

Although C # Can Understand attributes, they exist in the form of functions in the Il world. Thus, all attributes are converted to simple function calls. As the signature indicates this introduction, the write function or the write accessors pass a parameter. The value parameter is Row 1 in the param table.

So far, it has been good, but it will be noted that the link between the property table and the method table is missing. This association can be found in the methodsematic table. The methodsematic table is located on the 24th bits in the valid field.

The methodsematic table has the following columns:

Table 4-20

Table 4-21

This table starts with a 2-byte feature annotation. We create a function named getmethodsemantics, which checks whether these functions are on. The idea behind creating functions is that they can be used in the future.

In this function, encoding is done using a slightly unusual technique. In most cases, the combination of these bits may be on. So far, a check has been implemented to verify whether a specific bit is on. Accordingly, a value is returned. However, it also proves that this method is inefficient if we are eager to determine whether Multiple Digits are on.

Continue to modify our code. Correspondingly, in the function, as long as this bit is on, we will continue to add or connect to the string S. The final output is that the feature mark provides information about whether it is a getter or a setter. The possible values of this annotation are as follows:

Table 4-22

The 2nd fields in the semantics table point to a row in the method table. Therefore, the first row of the methodsematics table is a getter. It is related to row 2 in the method table. The latter indicates the get_aa function.

The last field named Association is a join to the property table. It uses a one-bit encoding index and the result is 1. Because row 1st of the property table is the property AA, it associates the getter flag with this property.

Table 4-23

Therefore, with the help of the methodsematic table, we have determined the missing join between the method table and the property table. Field join is considered more complex and it also handles events. We will conduct further research later.

Table 4-24

To sum up, the propertymap table discusses classes in the typedef table, which has properties in the property table.

Since then, the method table lists only the methods created as attribute output. Connecting the property table and the method table is the methodsematic table-by pointing them to functions and properties respectively.

FieldlayoutTable

B. CS

A. CS

Output

By default, according to the natural development pattern, the memory locates the fields allocated from the runtime to exist in the class or structure. In a specific environment, we need to manually determine the memory location. To do this, the structlayoutattribute in the program must be located before the class name. It will get the explicit value from the enumeration named layoutkind.

Fieldoffset includes offset and field. It is the final authorization to determine the layout (layout ). In B. CS, we pointed out 1st field I, so as to layout at the first 2nd positions, rather than 0. Furthermore, we must specify the fact that 2nd fields usually start at the end of the first field and should be replaced by the offset at 20. The fieldoffset feature must be placed on each instance program.

Rows are added to the fieldlayout table in various scenarios where fields are manually laid out. Their index locations in the valid table are 16. The fieldlayout table has the following columns:

Table 4-25

Table 4-26

The first field is an integer that stores the offset. The 2nd fields are an index in the field table. Therefore, row 1st points to the 1st field I in the field table, and row 2nd IN THE fieldlayout table is related to field J.

Table 4-27

This is quite straightforward!

Events and delegates

B. CS

The above example defines a delegate named pqr at the namespace level. The introduction of delegation, so that the method can be called in a type of safe way, not by convention. They are closely related to events. Let's take a look at the various tables used for creation.

TyperefTable

Some rows are omitted below

The typeref table reveals the fact that five types are associated in the Assembly. The first and last types always exist. However, with the creation of the Delegate, all three types, namely, multicastdelegate, iasyncresult, and asynccallback, all belong to the system namespace and will be extended. These references are produced by the Code introduced by the delegate class.

TypedefTable

Some rows are omitted below

In the previous section, we checked the rows in the typedef table. Both the pseudo type and the ZZZ type are created, just as in the previous section. As the delegate appears, a new row with the type name pqr will be added to this table. This is the type of the first class, that is, the place where sealed is added, thus preventing access to all other classes from being derived from it.

The extends field reveals which type pqr is derived from. It points to the 2nd rows in the typeref table, that is, the multicastdelegate class. Therefore, we can make sure that the -- delegate class is derived from the multicastdelegate class.

Now, let's take a look at the method table after 3rd rows to display the methods introduced by the delegate class.

MethodsTable

Some rows are omitted below

Row 3rd in the method table is a constructor. Since you cannot manually enter these functions, the impflag fields of these four functions are runtime. This is the first occasion we have encountered this sign. We will describe other signs later-virtual and newslot.

The constructor signature exposes two parameters. By checking the param table, we find that row 1 is a parameter named object, while Row 2 is a parameter named method. In the same tone, the 2nd function invoke has a parameter named P. The 3rd functions in the delegate are begininvoke, which accepts three parameters: P, callback, and object. Finally, we will encounter the endinvoke function, which gets a parameter named result.

Table 4-28

So far, you will find it easier to read the metadata table-this is obvious.

B. CS

In File B. CS, field a is declared as event type. The delegated eventhandler is stored in the system namespace. Let's take a look at the rows inserted into the metadata table.

TyperefTable

Some rows are omitted below

There are two additional types-introduced in Row 2 and row 4; The eventhandler used by the event and the delegate type. We will return to these types later.

The typedef table contains rows composed of pseudo classes and ZZZ classes. As a result, they are not displayed. Events, unlike delegates, are basically considered as a field. Therefore, a row is added to the field table.

Field table

Some rows are omitted below

With the introduction of events in the program, two rows will be added to the method table, namely add_a and remove_a. Later we will process the remaining flags in a separate process.

Function add_a gets a parameter named value, as verified by the param table. The first method named remove_a also obtains a parameter named value.

Therefore, the event is finally divided into two methods, add_eventname and remove_eventname.

Memberref

Some rows are omitted below

The memberref table exposes the fact that the event is related to the combine and remove methods. These two methods index row 4 in the typeref table, which represents the system. Delegate class. This signature will be introduced in subsequent chapters, because it is too confusing to be processed in a timely manner.

A. CS

Output

Every time we add an event to our code, the two tables will be added to our metadata. First, events are regarded as properties in terms of concept. The first table is the event table with the ID of 20.

The event table has the following columns:

Table 4-29

Table 4-30

The first field is always a flag field, and one of the two digits is on at most.

The flag value 0 x 2nd is a special event. However, the 0 x value requires special treatment of the event during the runtime to process the event in a special way.

Table 4-31

The geteventattributes function returns the event feature as a string. The first field is the event name. In our example, it is. The first field is a typedeforref encoded index. Two of them determine that the table is typedef, typeref, or typespec. In this example, it is the index of row 2nd in the typeref table, which indicates the eventhandler class in the system namespace.

Each event must be of a delegate type. The first 2nd tables are event tables, and the ID is 18.

The eventmap table has the following columns:

The 1st fields are indexes in the typedef table. The value is 2, which points to 2nd rows. The table has the class name zzz. Event A is created in class zzz. The 2nd fields in the eventmap table are indexes in the event table. It is related to the event index in the event table.

Table 4-34

Finally, the methodsematics class connects methods and events. You may remember that the methodsematics table includes the semantics, method, and association columns.

The 1st fields in methodsemanticsattribu may be addon or remove. It is followed by an index in the method table. After that, we have encountered add_a and remove_a, and then we will encounter event indexes in the event table, that is, the above method is connected. This table serves as a pipeline between properties and events and their methods.

B. CS

Output

In the preceding example, only three events are added to class ZZZ and two events are added to class yyy. The event table stores five events, and the eventmap table stores classes that contain these events. Xxx class does not include any events. This explains that it does not exist in the eventmap table.

Connecting an event with a class is indeed a strange and tricky problem, because the number of events is not stored in any location. You must access the eventmap table to determine the event rows in the eventlist. The number of events in the 1st class is determined based on the differences between the index of the 2nd row and the 1st row.

PinvokeTable

B. CS

A. CS

Output

In the preceding example, a method named MessageBox is used to obtain four parameters, which are composed of two integers and two strings. The code for this method is ended with a semicolon instead of being placed between two braces. In addition, there is a function named dllimport in this function.

Code is usually placed in DLL (dynamic link library. The code for running Windows is also placed in DLL, such as user32.dll and kernerl32.dll. This code is mainly written in C language. In the past, a large number of functions need to be compiled in C language, and then compiled in Intel assembly language, rather than Il. We can access this code from the C # program or any other. NET application.

To execute this code, we need to introduce the pinvoke function in the. NET world. Expand a dllinport feature to add a row to the moduleref table, which is located at 26th bits. The moduleref table has only one column, namely name, which is an index in the String Heap.

Currently, this table has a separate row. The index in the string table provides DLL names such as user32.dll.

Another table affected by the interoperability service is the implmap table. The position of this table is 28th bits. It includes detailed information about the methods that appear in the DLL.

The implmap table has the following columns:

Table 4-35

Table 4-36

The 1st fields are flags or attribute fields, which are solved with the help of the getpinvokeattributes function.

Table 4-37

The charset value indicates the character set used. Unicode is an international standard that promotes Computer Representation of any language in the world. This standard is called i18n because there are 18 characters between the letters I and N of the word internationalization.

Call conventions observe the parameters placed on the stack. After that, it selects the parameters that are granted the responsibility to clean up the stack.

The call Convention winapi will be used during windows development, and the parameters will be pushed to the stack in reverse order. Further, when a function is called, The called function traverses the stack to clear and store it back to its original location.

In the implmap table, the 2nd fields are memberforwarded. It is an encoding index. Therefore, the first two digits are used to determine whether it is an index in the field table or an index in the method table. The export field is not supported.

Table 4-38

The RVA of the first method in the methoddef table is 0, because the code of this function exists in the DLL user32.dll and is not in the current file. Flags directly indicates that the pinvokeimpl bit of this method is set to on. Also, signature indicates that the method is called with four parameters, and the offset in the param table starts at 1.

The last field is the index in the moduleref table, which provides the name of the DLL where the method resides.

Interface

B. CS

A. CS

Output

File B. CS has two interfaces named YYY and XXX. They all have one function in turn and have the same name ABC

. The class ZZZ is derived from the two interfaces. Because the function names are the same, the method name ABC must have the prefix of the interface name in the class.

Let's focus on the tables created. The first affected table is interfaceimpl, and its bit index in the valid table is 9.

The interfaceimpl table has the following columns:

Table 4-39

Table 4-40

The first field is the offset in the typedef table. Row 4 in this table involves the class name zzz. The 2nd parameters are a two-digit typedeforref encoded index. In the following section, a function is used to decode the encoding index. It checks the bit and returns the table name. Another function is used to shift right and return the index value.

Typedeforref encoded index, which is indexed to one of the following three tables: typedef, typeref, or typespec.

Table 4-41

In row 1st, the index value points to the row 2nd of the typedef table. Row 2nd has a YYY interface item. The first row of interfaceimpl points to the first row of the typedef table, that is, zzz. However, the interface index is currently Row 3 of the typedef table, that is, interface XXX.

Therefore, each class derived from an interface has a row in the interfaceimpl table. Because we are derived from two interfaces, there are two rows. The interface is a type in the typedef table, and the abstract and classsemanticsmask bits are on.

The first table to be filled is a methodimpl table, which is located at 2nd index bits.

The methodimpl table has the following columns:

Table 4-42

Table 4-43

The 1st fields are indexes of the typedef table. Because methods exist in the class zzz, both rows point to row 4 in this class or typedef table. The next two fields use the same methoddeforref encoding index, which has a separate bit-select between them, that is, methoddef (which is a definition) and methodref (it is a reference to a method ).

Two functions, similar to the interfaceimpl table, are implemented as return strings and values. The methodbody index points to the 3rd methods in the method table, that is, YYY. ABC, while methoddeclaration points to the 1st functions, that is, ABC.

Table 4-44

The RVA of this function is 0 because it belongs to the interface yyy. This is because the methodlist field in the typedef table has a value of 1.

The first row of the methodimpl table has a methodbody index pointing to the XXX. ABC method or 2nd rows. The methoddeclaration field is the abc function of interface xxx.

Therefore, the methodimpl table provides information about the original functions of the methoddeclaration field, which is overwritten by functions in the methodbody field of the class zzz.

Table 4-45

If the interface is composed of 100 methods, each method in the class ZZZ will be overwritten, resulting in another 100 rows in the methodimpl table.

Standalonesig table:

B. CS

A. CS

Output

In File B. CS, the main function has two local variables, one int and one string. Function ABC has a local variable and a bool type in sequence.

Each time a local variable is created in a method, a row is added to the standalonesig table. The standalonesig table is located at 17th locations in the valid field. This table has a field named signature, which is an index in the Blob heap.

This index starts with the number after 7. We have encountered this problem in the previous chapter. Next is the number of parameters and actual data types. Use the GetType function again to explain the data type.

Signatures stored in the Blob heap can be indexed by many other tables. Among them, we may face that the signature in the Blob heap does not have any metadata to index it. This is the case when a variable exists in a function. When appropriate, we will indicate the process for accessing these signatures.

Security and unsafe

B. CS

> Csc B. CS/unsafe

A. CS

Output

Program B. CS now includes two methods which are marked with the unsafe parameter. Whenever a pointer is used in a program, the unsafe modifier must be forcibly used. Further, when the above program is compiled, the/unsafe option is added to the compiler. Use a separate unsafe method-Add a row to the declsecurity table. The bit index of the declsecurity table is 14.

The declsecurity table has the following columns:

Table 4-46

Table 4-47

In addition to the declsecurity table, three rows are extended for the typeref table, resulting in three references. All three features are in the security namespace.

The 1st fields in the declsecurity table are short integers, which represent action. The value assigned to it originates from the securityaction enumeration in the namespace system. Security. permissions. The value ranges from 0 to 0xff, which is reserved for future standards. Because the current value is 8, we cannot explain what action is.

The 2nd fields are a two-digit hasdeclsecurity encoding index, which points to one of the following three entities, namely, typedef, methoddef, or assembly.

Table 4-48

This field is called a parent. Because the Assembly value is assigned, the security Permission applies to the entire assembly. The last parameter is the index of the Blob heap. This value is a unicode string system. Security. permissionset, which is a valid serialized CLI object graph.

Resources

Some rows are omitted below

Creates a text file named a.txt to store string resources. The resource is only a name-value pair. There are two names, namely Sonal and Vijay, whose values are mukhi and ram respectively. These resources will be placed in our EXE file and will be obtained using an API later.

Now, run the resgen program, that is, resgen a.txt, to create a file named A. Resources. After that, create another file named B .txt with Line Net = yes. Then, run the resgen program, that is, resgen B .txt.

Now, to add these two resource files to the EXE file, run the following command:

B. CS

Csc B. CS/Res: A. Resources/Res: B. Resources

/RES command line option to add resources to the EXE file. Now, let's use these closely connected metadata tables.

A. CS

Output

Every time a resource is added to the EXE file using the/RES option, a row is added to the manifestresource table, and its bit index in the valid field is 40.

The manifestresource table has the following columns:

Table 4-49

Table 4-50

The 1st fields are the offset of the distance, and the resources are stored in the executable file. This offset can be obtained from the resource data directory in the imageoptional header.

The CLR header contains an item for the resource and Their offset.

1st resources are stored at the offset of this value. The size of File A. Resources is 342 bytes. As a result of byte accumulation of this header, 2nd resources show an offset of 348. 2nd resources start directly after 1st. Thus, the offset field includes the offset byte starting from the resource.

The first field is the flags field, which generates information about whether the Assembly resources are public or exported, or whether the Assembly is private.

Table 4-51

The getmanifestresource function returns the corresponding string.

The 3rd fields are the name of the resource file. The 4th fields are implementation-encoded indexes that point to the file or assemblyref table.

The document clearly states that if implementation is an index in the file table, the index value must be 0. Index 0 indicates that the index is invalid.

Exported type

C. CS

> CSC/T: Module C. CS

This will generate a file C. netmodule for us.

B. CS

CSC/addmodule: C. netmodule B. CS

A. CS

Output

Two classes are created in file C. CS. Together with the/target options of the compiler, they are then compiled into a module that uses the module option. This leads to the creation of a module file with the. netmodule extension. Then, use the. addmodule option of the compiler to compile the file B. CS.

This results in two additional rows in the exportedtype table. The index position of the exportedtype table in the valid field is 39.

The exportedtype table has the following columns:

Table 4-52

Table 4-53

The 1st fields are flags and belong to the typeattributes type. It shows the general identifier of each class. The 2nd fields are a little complicated. It is called typedefid. This value is the index of the typedef table of another module in the Assembly. However, it is only used as a reference.

Before proceeding to the next step, it is necessary to verify that other tables also contain the same name and namespace. In this example, the displayed value is quite large. As a result, we may not be able to accomplish anything worth doing. The first is the name of the class. The first is the namespace name. The 5th index is implementation encoded and points to the 1st rows of the file table.

Therefore, to sum up, the exportedtype table has only one row, which is used to define the type in other modules of our Assembly and its export. These types are obviously marked as public.