This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!
Assembly Manifest
An assembly’s manifest contains information on all items considered part of an assembly; this information is known as the assembly's metadata. The manifest determines what items are exposed outside of the assembly and what items are accessible only within the current assembly’s scope. The assembly’s manifest also contains a collection of references to other assemblies. These references are resolved by the runtime based on information stored in the manifest. The assembly's manifest contains all information needed to use an assembly.
As you can see from the above illustration, the manifest can be stored in several ways. For an assembly with one associated file, the manifest is incorporated into the PE file to form a single-file assembly. A multi-file assembly can be created with either the manifest as a stand-alone file or incorporated into one of the PE files in the assembly.
From an external view (i.e. that of the assembly consumer), an assembly is a named and version-constrained collection of exported types and resources. From the internal view (i.e. that of the assembly developer), an assembly is a collection of one or more files that implement types and resources. Each assembly’s manifest enumerates the files that make up the assembly and governs how references to the assembly's types and resources are mapped to the files that contain their declarations and implementations. The manifest also enumerates other assemblies on which it depends. The existence of a manifest provides a level of indirection between consumers of the assembly and the implementation details of the assembly and renders assemblies self-describing.
The manifest contains the following information:
- Assembly name - contains a friendly, textual string name.
- Version information -consists of a major and minor version number, and a revision and build number. These numbers are used by the runtime when enforcing version policy. For more information on version policy, see Versioning Issues.
- Shared name information - contains a hash of the file containing the manifest encrypted and a public key from the assembly's originator. For more information on shared names, see Shared Assemblies.
- Culture, processor and OS supported - contains information on the cultures, processors, and operating systems the assembly supports.
- List of all files in the assembly - consists of a hash of each file contained in the assembly and of each dependent assembly's manifest.
- Type reference information - contains information used by the runtime to map a type reference to the file that contains its declaration and implementation.
- Information on referenced assemblies - contains a list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assesmbly's name, metadata (version, culture, OS, etc.), and public key if the assembly is shared.
A developer can also set, in code, custom assembly attributes. These custom attributes include:
- Title - Provides a friendly name, which can include spaces. For example, the assembly name of an assembly might be “comdlg,” while the assembly title would be “Microsoft Common Dialog Control.”
- Description - a short description of the assembly.
- Default Alias - Provides a friendly default alias in cases where the assembly name is not friendly or a GUID. For example, in COM interoperability, the generated assembly name will be the GUID of the type library, while the default alias will be the friendly type library name.
- Configuration information - consists of a string that can be set to any value for configuration information such as Retail or Debug.
- Product information such as Trademark, Copyright, Product, Company, and InformationalVersion.
For more information on setting an assembly's custom attributes, see Assembly Custom Attributes.