Merge modules into an assembly

The program.exe file discussed earlier is not only a PE file with metadata, but also an assembly ). an assembly is a collection of one or more files containing Type Definitions and resources. the file that makes up an assembly is put into manifest. manifest is another set of metadata tables, including the name of the file that makes up the Assembly. They also describe the assembly version, language, and publisher, publicly exposed types and all files that make up the assembly.

CLR operates on the Assembly. That is to say, CLR always Loads files containing the manifest table first, and then obtains other files in the Assembly through manifest. The following are the characteristics of the Assembly that you should remember:

The Assembly defines reusable types.

The Assembly is marked with the version number.

An assembly can have security information associated with it.

Files contained in the Assembly do not have to have these attributes-except the files containing the manifest metadata table.

For software packages, versions, security, and types, you must put them in the module. In most cases, an Assembly contains only one file, which is an example of program.exe. However, A program can contain multiple files: Some PE files that contain metadata, and some resource files, such as. GIF or. jpg files. you can think of an assembly as a logical EXE or DLL.

I think many people will askWhy does Microsoft introduce the new concept of assembly, The reason is that the Assembly allows you to separate logical type reuse from physical type reuse.. For example, an assembly can be composed of multiple types. You can put frequently-used types in one file, but not commonly-used types in another file, if your assembly is published over the Internet and the client never accesses uncommon types, the files in which they are located will never need to be downloaded to the client. for example, if an independent software vendor (isV) focuses on the UI control, it may choose to implement the active accessibility type (to meet Microsoft's logo requirements) in a separate module ). only users who need this additional accessibility function need to download this module.

You can configure the application to download the Assembly file by specifying the codebase element in the application configuration file. the codebase element provides a URL to point to the location of the Assembly file. when attempting to load an assembly file, CLR obtains the URL of the codebase element and checks the download cache of the machine to check whether the file exists. If the file exists, it loads the file. If the file is not in the cache, the CLR will download the file and put it in the cache. If the file is not found at the URL location, it will throw filenotfoundexception.

I foundThree reasons for using multi-file assembly:

YouYou can place different types of files in different files, which allows the files to be downloaded one by one.For example, in the Internet download scenario mentioned above, separating different types of files can also partially package and deploy the applications you want to purchase.

YouYou can add resources or data files in your set.. For example, you may have a calculator that calculates an insurance information. This type may need to access some insurance statistical tables to complete its calculation. you do not need to embed an insurance statistical table into your source code. You can use a tool (such as Assembly Linker and al.exe, which will be discussed later) to make the data file part of the Assembly. in this way, the data file can be in any format, such as text files, Office EXCEL tables, offfice Word tables, or any other data you want to use, as long as your application knows how to parse the file content.

YouYou can create an Assembly that contains implementation types in different languages.For example, you can use C # To implement some types, VB to implement other types, and other languages to implement other types. when you compile a type in the source code written in C #, the compiler will generate a module. when you compile a type in the source code written in VB, the compiler will generate another module. then you can use a tool to combine all modules to generate an assembly. for developers who use an assembly, the Assembly is just like a group of types. Developers do not need to know that the Assembly uses different languages. in this way, if you want to, you can run ildasm.exe on each worker to obtain the Il source code file. Then you can run ilasm.exe and input all the Il source code files, which will generate a separate file containing all types, this technology requires your source code compiler to generate the IL-only code.

Important: To sum up, an assembly is a unit of reuse, version control, and security control. it allows you to put multiple types of resources into different files, so that you and the customers who use the Assembly decide which files to package and deploy. once the CLR loads a file that contains manifest, it can determine which files of the Assembly contain types and resources. The people who use the Assembly only need to know the file name that contains manifest, and the file separation is abstracted out, in the future, you can change the splitting method without affecting the application behavior.

If you have multiple types, they can share a version number and security settings, we recommend that you put all types in a separate file, instead of distributing them to different files, do not put it in different assemblies. This is because of performance. loading a file/Assembly consumes Clr and Windows Time to locate the Assembly, load the assembly, and initialize it. the smaller the number of files/Assembly loads, the better, because Loading Less program Assembly helps you reduce the working set and reduce the fragmentation of the process address space. finally, ngen.exe can perform better optimization when processing large files.

To build an assembly, You must select a PE file to include manifest, or you can create a separate file to only include manifest. The following table lists the manifest metadata table:

Manifest metadataTable	Description
Assemblydef	If this module identifies an assembly, it only contains one entry. this entry includes the Assembly name (without path and extension), version (main version number, minor version number, build version number, modification version number), language, flag, and hash algorithm, issuer's public key (which can beNull).
Filedef	Each PE and resource file (except the file containing manifest, because it is in the assemblydef table) contains an entry, including the file name and Extension (no path), hash value, and flag. if this Assembly contains only one file, there is no entry in the filedef table.
Manifestresourcedef	Each resource contains an entry. The entry includes the resource name, flag (public if visible to the external assembly, private if not), and an index pointing to the filedef table. if the resource is not an independent file (such as a .jpg or .gif file), the resource is a stream contained in the PE file. for an embedded resource, the entry also contains an offset to indicate the starting position of the resource stream in the PE file.
Exportedtypesdef	Each public type contains an entry. The entry includes the type name, an index pointing to the filedef table (indicating that the file has implemented this type), and an index pointing to the typedef table. note: To save space, the export type in the file containing manifest does not need to be repeated in this table, because the type information can be obtained in the typedef table in metadata.

Manifest provides an indirect level between the customer and the Assembly's segmentation details, so that the Assembly is self-described. remember that files containing manifest have metadata information, which indicates that these files are part of the Assembly, but the separate files do not have metadata information.

Note: The Assembly file containing manifest also has an assemblyref table, which contains an entry for each other Assembly referenced by this Assembly. This allows the tool to open the manifest of an assembly, view the referenced assembly without opening other files of the Assembly. entries in the assemblyref table make the Assembly self-described.

When you specify any of the following command line switches, the C # compiler generates an assembly:/T [arget]: EXE,/t [arget]: winexe, or/T [arget]: Library. these switches will make the compiler generate a separate PE file, which contains the manifest metadata table, the generated file, Cui executable program, Gui executable program, or a DLL.

In addition to these switches, the C # compiler supports the/T [arget]: module switch, which tells the compiler to generate a PE file that does not contain the manifest metadata table, the generated PE file is always a dll pe file, which must be added to a program set before CLR can access the type in it. when you use the/T: module switch, the C # compiler will add one in the output file by default. netmodule extension.

Important: Unfortunately, Microsoft's Integrated Visual Studio development environment (IDE) does not support multi-file assembly creation. If you want to create multi-file assembly, you must turn to the command line tool.

There are many ways to add modules to an assembly. If you use the C # compiler to build a PE file with manifest, you can use the/addmodule switch. to understand how to build a multi-file assembly, let's assume that you have two source code files:

Rut. CS: Contains rarely used types

Fut. CS: Contains frequently used types

Let's compile the rarely used types into their own modules, so that the Assembly users do not need to deploy this module, if users do not need to access this rarely used type.

CSC/T: module rut. CS

This command causes the C # compiler to create a rut. netmodule file, which is a standard dll pe file. However, the CLR cannot load it only through this file.

Next let's compile the frequently used types for their own modules. We will make this module Save the manifest of the Assembly, because the types in this module are frequently used. actually, because this module will represent the entire assembly, I will change the name of the output file to jefftypes. DLL instead of the default fut. DLL.

CSC/out: jefftypes. dll/T: Library/addmodule: rut. netmodule fut. CS

This command tells C # compiler to compile fut. CS file and generate jefftypes. DLL file. because/T: Library is specified, a dll pe file containing the manifest metadata table is put in jefftypes. DLL file. /addmodule: rut. the netmodule switch tells the compiler rut. netmodule is a file, which should be considered a part of the Assembly. specifically, the/addmodule switch tells the compiler to add a file to the filedef manifest metadata table to put rut. the publicly exposed type of netmodule is added to the exportedtypesdef manifest metadata table.

When the compiler completes all these operations, the two files created are shown in Figure 2-1, and the module on the right contains manifest.

Rut. the netmodule file contains il code (by compiling rut. CS). This file also contains the metadata table, which describes rut. type, method, field, attribute, event, and so on defined in CS. this metadata mark also describes rut. the type, method, and so on referenced in CS. jefftypes. DLL is a separate file, similar to rut. netmodule. This file contains the Il code (compile fut. CS). This file contains similar definitions and references to the metadata table. however, jefftypes. the DLL also contains an additional manifest metadata table to make jefftypes. DLL is an assembly. this additional manifest metadata table describes all the files that make up the Assembly (jefftypes. DLL file itself and rut. netmodule file ). the manifest metadata table also contains all jefftypes. DLL and rut. type exposed by netmodule.

Note: in fact, the manifest metadata table does not have any type exposed in "PE file containing manifest". This optimization aims to reduce the number of bytes of manifest information in the PE file, therefore, the statement "manifest metadata table also contains all jefftypes. DLL and rut. the Type exposed by netmodule "is not 100% accurate. however, this statement accurately reflects the logic exposure of manifest.

When jefftypes. DLL assembly. You can use ildasm.exe to check the manifest table of metadata to verify that the Assembly file really contains rut. the type in the netmodule file. jefftypes is extracted below. the filedef and exportedtypesdef metadata tables in DLL metadata are as follows:

List of included external files:

File #1 (26000001)

-----------------------------------------------------

Token: 0x26000001

Name:Rut. netmodule

Hashvalue BLOB: E6 E6 DF 62 2C Al 2C 59 97 65 0f 21 44 10 15 96 F2 7E dB C2

Flags: [containsmetadata] (00000000)

Types in the configuration file:

Exportedtype #1 (27000001)

-----------------------------------------------------

Token: 0x27000001

Name:Ararelyusedtype

Implementation token: 0x26000001

Typedef token: 0x02000002

Flags: [public] [autolayout] [Class] [sealed] [ansiclass]

[Beforefieldlnit] (00100101)

From this example, we can see that rut. netmodule is a file and a part of the Assembly. Its token is 0x26000001. from the exportedtypesdef table, we can see that there is a publicly exposed arararelyusedtype. the token of this type is 0x26000001, which indicates that this type of IL code is included in rut. in the netmodule file.

Note: Out of curiosity, metadata token is a 4-byte value. The high byte represents the token type (0x01 = typeref, 0x02 = typedef, 0x23 = assemblyref, 0x26 = fileref, 0x27 = exportedtype ). for the complete list, see corhdr. the cortokentype Enumeration type in H. This file is.. NET Framework SDK. the three low-byte columns show the rows in the corresponding metadata table. for example, Token 0x000001 references the first row of the fileref table. for most tables, rows are counted from 1 instead of 0. for a typedef table, rows are counted from 2.

Use jefftypes for any client code. DLL assembly type, which must use/R [eference]: jefftypes. DLL compiler switch to build. this switch tells the compiler to load jefftypes. DLL assembly and all files listed in its filedef table (when searching for external types ). the compiler requires all Assembly files if you delete rut. netmodule file, C # compiler will produce the following error: "Fatal error cs0009: Metadata File 'C: \ jefftypes. DLL cocould not be opened-'error importing module 'rut. netmodule 'of Assembly 'C: \ jefftypes. dll '-the system cannot find the file specified '".This means that in order to build a new Assembly, all files in the referenced assembly must exist..

When the client code is executed, it calls the corresponding function. if the function is called for the first time, the CLR checks the parameter type, return value type, and local variable type referenced by the function. then CLR tries to load the referenced assembly file (containing the manifest assembly ). if the type being accessed is in this file, the CLR executes the internal logic and allows the type to be used. if manifest indicates that the referenced type is in a different file, CLR attempts to load necessary files, execute internal logic, and allow access types. the CLR loads the corresponding Assembly file only when a method references a type in an assembly that is not loaded.This means that running an application does not have to exist all the files in the referenced assembly.