A managed PE file has four main parts:
- PE32(+) header
The PE32(+) header is the standard information that Windows expects
- CLR header
The CLR header is a small block of information that is specific to modules that require the CLR (managed modules). The header includes the major and minor version number of the CLR that the module was built for: some flags, a MethodDef token indicating the module’s entry point method if this module is a CUI or GUI executable, and an optional strong-name digital signature. Finally, the header contains the size and offsets of certain metadata tables contained within the module. You can see the exact format of the CLR header by examining the IMAGE_COR20_HEADER defined in the CorHdr.h header file.
The metadata is a block of binary data that consists of several tables. There are three categories of tables: definition tables, reference tables, and manifest tables. Table below describes some of the more common definition tables that exist in a module’s metadata block.
Common Reference Metadata Tables
an assembly is a unit of reuse, versioning, and security. It allows you to partition your types and resources into separate files so that you, and consumers of your assembly, get to determine which files to package together and deploy. Once the CLR loads the file containing the manifest, it can determine which of the assembly’s other files contain the types and resources the application is referencing. Anyone consuming the assembly is required to know only the name of the file containing the manifest; the file partitioning is then abstracted away from the consumer and can change in the future without breaking the application’s behavior.
Below is Manifest Metadata tables
To make your own assemblies appear in the .NET tab’s list, add the following subkey to the registry:
MyLibName is a unique name that you create—Visual Studio doesn’t display this name. After creating the subkey, change its default string value so that it refers to a directory path (such as C:\Program Files\MyLibPath) containing your assembly’s files. Using HKEY_LOCAL_MACHINE adds the assemblies for all users on a machine; use HKEY_CURRENT_USER instead to add the assemblies for a specific user.
If you’re designing an application that has some culture-specific resources to it, Microsoft highly recommends that you create one assembly that contains your code and your application’s default (or fallback) resources. When building this assembly, don’t specify a culture. This is the assembly that other assemblies will reference when they create and manipulate types it publicly exposes.
Now you can create one or more separate assemblies that contain only culture-specific resources—no code at all. Assemblies that are marked with a culture are called satellite assemblies. For these satellite assemblies, assign a culture that accurately reflects the culture of the resources placed in the assembly. You should create one satellite assembly for each culture you intend to support.