An assembly is the logical unit that contains compiled code targeted at the .NET Framework. Assemblies
are not covered in detail in this chapter because they are covered thoroughly in Chapter 17 ,
“ Assemblies, ” but we summarize the main points here.
An assembly is completely self - describing and is a logical rather than a physical unit, which means that
it can be stored across more than one file (indeed, dynamic assemblies are stored in memory, not on file
at all). If an assembly is stored in more than one file, there will be one main file that contains the entry
point and describes the other files in the assembly.
Note that the same assembly structure is used for both executable code and library code. The only real
difference is that an executable assembly contains a main program entry point, whereas a library
assembly does not.
An important characteristic of assemblies is that they contain metadata that describes the types and
methods defined in the corresponding code. An assembly, however, also contains assembly metadata
that describes the assembly itself. This assembly metadata, contained in an area known as the manifest ,
allows checks to be made on the version of the assembly, and on its integrity.
The fact that an assembly contains program metadata means that applications or other assemblies that
call up code in a given assembly do not need to refer to the registry, or to any other data source, to find
out how to use that assembly. This is a significant break from the old COM way of doing things, in which
the GUIDs of the components and interfaces had to be obtained from the registry, and in some cases, the
details of the methods and properties exposed would need to be read from a type library.
Having data spread out in up to three different locations meant there was the obvious risk of something
getting out of synchronization, which would prevent other software from being able to use the
component successfully. With assemblies, there is no risk of this happening, because all the metadata is
stored with the program executable instructions. Note that even though assemblies are stored across
several files, there are still no problems with data going out of synchronization. This is because the file
that contains the assembly entry point also stores details of, and a hash of, the contents of the other files,
which means that if one of the files gets replaced, or in any way tampered with, this will almost certainly
be detected and the assembly will refuse to load.
are not covered in detail in this chapter because they are covered thoroughly in Chapter 17 ,
“ Assemblies, ” but we summarize the main points here.
An assembly is completely self - describing and is a logical rather than a physical unit, which means that
it can be stored across more than one file (indeed, dynamic assemblies are stored in memory, not on file
at all). If an assembly is stored in more than one file, there will be one main file that contains the entry
point and describes the other files in the assembly.
Note that the same assembly structure is used for both executable code and library code. The only real
difference is that an executable assembly contains a main program entry point, whereas a library
assembly does not.
An important characteristic of assemblies is that they contain metadata that describes the types and
methods defined in the corresponding code. An assembly, however, also contains assembly metadata
that describes the assembly itself. This assembly metadata, contained in an area known as the manifest ,
allows checks to be made on the version of the assembly, and on its integrity.
The fact that an assembly contains program metadata means that applications or other assemblies that
call up code in a given assembly do not need to refer to the registry, or to any other data source, to find
out how to use that assembly. This is a significant break from the old COM way of doing things, in which
the GUIDs of the components and interfaces had to be obtained from the registry, and in some cases, the
details of the methods and properties exposed would need to be read from a type library.
Having data spread out in up to three different locations meant there was the obvious risk of something
getting out of synchronization, which would prevent other software from being able to use the
component successfully. With assemblies, there is no risk of this happening, because all the metadata is
stored with the program executable instructions. Note that even though assemblies are stored across
several files, there are still no problems with data going out of synchronization. This is because the file
that contains the assembly entry point also stores details of, and a hash of, the contents of the other files,
which means that if one of the files gets replaced, or in any way tampered with, this will almost certainly
be detected and the assembly will refuse to load.
No comments:
Post a Comment