Understanding the .NET Framework - Assemblies
(Page 5 of 8 )
Now that you've seen an overview of the different Namespaces that are included in the .NET Framework, it's time to look a little closer at the executable programs, or in .NET parlance, the assemblies that are created using the classes contained in those Namespaces. Assemblies are basically a new way of packaging executable code. Like the programs produced by earlier compilers, such as Visual C++, the assemblies that are created by the .NET compilers typically end with the file extension of .exe or .dll. However, unlike those programs that contain native x86 machine instructions, which can be directly executed by the Windows operating system, the assemblies output by the .NET compilers contain a combination of MSIL, metadata, and resources such as bitmaps. Assemblies cannot be executed without the presence of the .NET CLR. The metadata information that's stored in the assembly is known as the manifest, and it contains information about the resources within the assembly, as well as its dependencies. The Type metadata contain the CTS types that are used in the assembly. The executable code, or MSIL, is a platform-independent intermediate language that is a higher level than the native machine code produced by older compilers. Unlike standard x86 executable code, MSIL understands objects and has instructions that can instantiate and manipulate object properties. Similarly, MSIL contains facilities to raise and catch exceptions. Finally, the resources in an assembly typically contain the bitmaps, icons, and other binary resources that are used by the application. Figure 2-3 presents an overview of the internal stature of a single file assembly.
Unlike standard executable files, assemblies can be single file, or they can be contained in multiple files. For instance, an assembly could be split into three different files where one contained the metadata, another contained the MSIL, and another contained the resource and bitmaps used by the application. Multifile assemblies are typically used to support multiple-language applications. Figure 2-4 illustrates an example multifile assembly.
Figure 2-3. Sample single file assembly
In Figure 2-4, you can see that the code and resources are split between three different physical files. In this case, note that the manifest contained in the base MyAssembly.exe points to the other assemblies that are used. There are no Registry entries or other on-disk structures that are used to link together the different assembly components. The self-describing metadata is responsible for managing the assembly components. You'll find more information about the metadata contained in the assembly in the next section, "Assembly Manifest."
Figure 2-4. Sample multifile assembly
In addition to containing the executable program instructions, assemblies fulfill several important roles in the .NET Framework. First, assemblies define a security boundary. The assembly is the unit to which .NET permissions are granted. This security information enables a very granular level of security that was never possible with Win32 applications. .NET security can restrict and grant access at the function level of an application. Next, the assembly's manifest contains versioning information. This versioning information both identifies the current assembly and defines the version requirements for any required assemblies. Because each assembly carries with it its own version identification, as well as the version information of all dependent components, there is no possibility of an older version of a component or some otherwise incorrect but like-named component being accidentally installed and used. Next, the assembly limits the scope of the types contained in the assembly. Each type is contained within the bounds of its assembly. Identically named types in different assemblies are managed independently. Finally, an assembly forms the basic unit of deployment for a .NET application. When deploying a .NET application, you essentially just need to copy the assembly to the target system. The assembly's metadata is responsible for finding any required components.
When an assembly is created, it can be made as private or shared. Private assemblies can be used only by a single application, whereas shared assemblies can be used by multiple applications. Multiple versions of a given assembly can be simultaneously installed on the same machine. Assemblies can also be either static or dynamic. A static assembly resides in a PE (Portable Executable) file that's stored as an on-disk structure. A dynamic assembly is created and executed directly in memory, and it's not saved to disk.
 This is chapter two of ADO.NET: The Complete Reference, by Michael and Denielle Otey (McGraw-Hill/Osborne, ISBN 0-07-222898-9, 2003). Check it out at your favorite bookstore today. Buy this book now. |
Next: Assembly Manifest >>
More .NET Articles
More By McGraw-Hill/Osborne
/ 28 
