Assemblies are the building blocks of .NET Framework applications; they form the
fundamental unit of deployment, version control, reuse, activation scoping, and
security permissions. An assembly is a collection of types and resources that are
built to work together and form a logical unit of functionality. An assembly provides
the common language runtime with the information it needs to be aware of type
implementations. To the runtime, a type does not exist outside the context of an
assembly.
An assembly does the following functions:
• It contains the code that the runtime executes.
• It forms a security boundary. An assembly is the unit at which permissions are
requested and granted.
• It forms a type boundary. Every type’s identity includes the name of the
assembly at which it resides.
• It forms a reference scope boundary. The assembly's manifest contains assembly
metadata that is used for resolving types and satisfying resource requests. It
specifies the types and resources that are exposed outside the assembly.
• It forms a version boundary. The assembly is the smallest version able unit in the
common language runtime; all types and resources in the same assembly are
versioned as a unit.
• It forms a deployment unit. When an application starts, only the assemblies the
application initially calls must be present. Other assemblies, such as localization
resources or assemblies containing utility classes, can be retrieved on demand.
This allows applications to be kept simple and thin when first downloaded.
• It is a unit where side-by-side execution is supported.
Contents of an Assembly
• Assembly Manifest
• Assembly Name
• Version Information
• Types
• Locale
• Cryptographic Hash
• Security Permissions
Assembly Manifest
Every assembly, whether static or dynamic, contains a collection of data that
describes how the elements in the assembly relate to each other. The assembly
manifest contains this assembly metadata. An assembly manifest contains the
following details:
• Identity. An assembly's identity consists of three parts: a name, a version
number, and an optional culture.
• File list. A manifest includes a list of all files that make up the assembly.
• Referenced assemblies. Dependencies between assemblies are stored in the
calling assembly's manifest. The dependency information includes a version
number, which is used at run time to ensure that the correct version of the
dependency is loaded.
• Exported types and resources. The visibility options available to types and
resources include "visible only within my assembly" and "visible to callers outside
my assembly."
• Permission requests. The permission requests for an assembly are grouped into
three sets: 1) those required for the assembly to run, 2) those that are desired
but the assembly will still have some functionality even if they aren't granted,
and 3) those that the author never wants the assembly to be granted.
In general, if you have an application comprising of an assembly named Assem.exe
and a module named Mod.dll. Then the assembly manifest stored within the PE
Assem.exe will not only contain metadata about the classes, methods etc. contained
within the Assem.exe file but it will also contain references to the classes, methods
etc, exported in the Mod.dll file. While the module Mod.dll will only contain metadata
describing itself.
The following diagram shows the different ways the manifest can be stored:
fundamental unit of deployment, version control, reuse, activation scoping, and
security permissions. An assembly is a collection of types and resources that are
built to work together and form a logical unit of functionality. An assembly provides
the common language runtime with the information it needs to be aware of type
implementations. To the runtime, a type does not exist outside the context of an
assembly.
An assembly does the following functions:
• It contains the code that the runtime executes.
• It forms a security boundary. An assembly is the unit at which permissions are
requested and granted.
• It forms a type boundary. Every type’s identity includes the name of the
assembly at which it resides.
• It forms a reference scope boundary. The assembly's manifest contains assembly
metadata that is used for resolving types and satisfying resource requests. It
specifies the types and resources that are exposed outside the assembly.
• It forms a version boundary. The assembly is the smallest version able unit in the
common language runtime; all types and resources in the same assembly are
versioned as a unit.
• It forms a deployment unit. When an application starts, only the assemblies the
application initially calls must be present. Other assemblies, such as localization
resources or assemblies containing utility classes, can be retrieved on demand.
This allows applications to be kept simple and thin when first downloaded.
• It is a unit where side-by-side execution is supported.
Contents of an Assembly
• Assembly Manifest
• Assembly Name
• Version Information
• Types
• Locale
• Cryptographic Hash
• Security Permissions
Assembly Manifest
Every assembly, whether static or dynamic, contains a collection of data that
describes how the elements in the assembly relate to each other. The assembly
manifest contains this assembly metadata. An assembly manifest contains the
following details:
• Identity. An assembly's identity consists of three parts: a name, a version
number, and an optional culture.
• File list. A manifest includes a list of all files that make up the assembly.
• Referenced assemblies. Dependencies between assemblies are stored in the
calling assembly's manifest. The dependency information includes a version
number, which is used at run time to ensure that the correct version of the
dependency is loaded.
• Exported types and resources. The visibility options available to types and
resources include "visible only within my assembly" and "visible to callers outside
my assembly."
• Permission requests. The permission requests for an assembly are grouped into
three sets: 1) those required for the assembly to run, 2) those that are desired
but the assembly will still have some functionality even if they aren't granted,
and 3) those that the author never wants the assembly to be granted.
In general, if you have an application comprising of an assembly named Assem.exe
and a module named Mod.dll. Then the assembly manifest stored within the PE
Assem.exe will not only contain metadata about the classes, methods etc. contained
within the Assem.exe file but it will also contain references to the classes, methods
etc, exported in the Mod.dll file. While the module Mod.dll will only contain metadata
describing itself.
The following diagram shows the different ways the manifest can be stored:
Comments
Post a Comment