.NET Architecture—Assemblies
| CSharp-Online.NET:Articles |
| .NET Articles |
| © 2006 Wiley Publishing, Inc. |
Assemblies
An assembly is the logical unit that contains compiled code targeted at the .NET Framework. Assemblies are not covered in great detail in this chapter because they are covered in detail in Chapter 15, “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 doesn’t.
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.
ildasm, a Windows-based utility, can be used to inspect the contents of an assembly, including the manifest and metadata.
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, in order 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.
Assemblies come in two types: shared and private assemblies.
 
|
