The definition of an assembly also largely depends on how you're using it. From a client's perspective, an assembly is a named and versioned collection of modules, exported types, and, optionally, resources. From the assembly creator's viewpoint, an assembly is a means of packaging related modules, types, and resources and exporting only what should be used by a client. Having said that, it's the manifest that provides the level of indirection between the implementation details of the assembly and what the client is meant to use. Here's a breakdown of the information that gets stored in an assembly's manifest: -
Assembly name The textual name of the assembly.
Versioning information This string contains four distinct parts that make up a version number. They include a major and minor version number as well as a revision and build number.
An (optional) shared name and signed assembly hash This information pertains to the deployment of assemblies and is covered in "Assembly Deployment" later in this tutorial.
Files This list includes all files that exist in the assembly.
Referenced assemblies This is a list of all external assemblies that are directly referenced from the manifest's assembly.
Types This is the list of all types in the assembly with a mapping to the module containing the type. This data is what helps the reflection example in tutorial 16 (that iterates through all the types in an assembly) execute so quickly.
Security permissions This is a list of security permissions that are explicitly refused by the assembly.
Custom attributes tutorial 8, "Attributes," described creating your own custom attributes. As with types, custom attributes are stored in the assembly's manifest for quicker access during reflection.
Product information This information includes Company, Trademark, Product, and Copyright values.