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.

Difference between manifest ,

metadata?
Manifest Maintains the information about the assemblies

like version, name locale and an optional strong name that

uniquely identifying the assembly. This manifest
information is used by the CLR. The manifest also contains
the security demands to verify this assembly. It also
contains the names and hashes of all the files that make
up the assembly. The .NET assembly manifest contains a
cryptographic hash of different modules in the assembly.
And when the assembly is loaded, the CLR recalculates
the hash of the modules at hand, and compares it with the
embeded hash. If the hash generated at runtime is
different from that found in the manifest, .NET refuses to
load the assembly and throws an exception.

Metadata means Data about the data. metadata

yields the types available in that assembly, viz.

classes, interfaces, enums, structs, etc., and their
containing namespaces, the name of each type, its
visibility/scope, its base class, the interfaces it
implemented, its methods and their scope, and
each methods parameters, types properties, and
so on. The assembly metada is generated by the
high-level compilers automatically from the source
files. The compiler embeds the metadata in the
target output file, a dll, an .exe.

Assemblies
.assembly extern < assembly name >
Specifies another assembly that contains items referenced by the current module (in this example,

mscorlib).
.publickeytoken < token >
Specifies the token of the actual key of the referenced assembly.
.ver < version number >
Specifies the version number of the referenced assembly.
.assembly < assembly name >
Specifies the assembly name.
.hash algorithm < int32 value >
Specifies the hash algorithm used.
.ver < version number >
Specifies the version number of the assembly.
.module < file name >
Specifies the name of the modules that make up the assembly. In this example, the assembly consists of
only one file.
.subsystem < value >
Specifies the application environment required for the program. In this example, the value 3 indicates
that this executable is run from a console.
.corflags
Currently a reserved field in the metadata.

Assemblies are designed to simplify

application deployment and to solve

versioning problems .
Assemblies Promote Code Reuse
Assemblies Are Self-Describing
Assemblies can be deployed as private or

shared. Private assemblies reside in the

same directory (or possibly a subdirectory) as
the client application making use of them.
Shared assemblies, on the other hand, are
libraries intended to be consumed by
numerous applications on a single machine
and are deployed to a specific directory

Assemblies deployed in the global assembly

cache must have a strong name. When an

assembly is added to the global assembly
cache, integrity checks are performed on all
files that make up the assembly. The cache
performs these integrity checks to ensure that
an assembly has not been tampered with, for
example, when a file has changed but the
manifest does not reflect the change.
A strong name consists of the assembly's
identity its simple text name, version
number, and culture information (if provided)
plus a public key and a digital signature.
You can ensure that a name is globally unique
by signing an assembly with a strong name.

There are several reasons why you might

want to install an assembly into the global

assembly cache:
Shared location.
File security.
Side-by-side versioning.
Additional search location.