Day -13 : Chapter 15 Introduction to Assemblies

Chapter 15 deals with Assemblies and their configuration.
Properties of assemblies -

·         Assemblies Promote Code Reuse

·         Assemblies Establish a Type Boundary

·         Assemblies Are Versionable Units

·         Assemblies Are Self-Describing

·         Assemblies Are Configurable

A .NET assembly (*.dll or *.exe) consists of the following elements:

·         A Win32 file header - The Win32 file header establishes the fact that the assembly can be loaded and manipulated by the Windows family of operating systems. This header data also identifies the kind of application to be hosted by the Windows operating system.

·         A CLR file header - The CLR header is a block of data that all .NET files must support  in order to be hosted by the CLR. In a nutshell, this header defines numerous flags that enable the runtime to understand the layout of the managed file.

·         CIL code - At its core, an assembly contains CIL code, which as you recall is a platform- and CPU-agnostic intermediate language. At runtime, the internal CIL is compiled on the fly (using a just-in-time [JIT] compiler) to platform- and CPU-specific instructions. Given this architecture, .NET assemblies can indeed execute on a variety of architectures, devices, and operating systems.

·         Type metadata - An assembly also contains metadata that completely describes the format of the contained types as well as the format of external types referenced by this assembly. The .NET runtime uses this metadata to resolve the location of types (and their members) within the binary, lay out types in memory, and facilitate remote method invocations

·         An assembly manifest - An assembly must also contain an associated manifest (also referred to as assembly metadata). The manifest documents each module within the assembly, establishes the version of the assembly, and also documents any external assemblies referenced by the current assembly.

·          Optional embedded resources - Finally, a .NET assembly may contain any number of embedded resources such as application icons, image files, sound clips, or string tables.

Private Assemblies - Private assemblies are required to be located within the same directory as the client application. The full identity of a private assembly consists of the friendly name and numerical version, both of which are recorded in the assembly manifest.

The .NET runtime resolves the location of a private assembly using a technique termed probing, which is much less invasive than it sounds. Probing is the process of mapping an external assembly request to the location of the requested binary file.

Shared Assemblies - The most obvious difference between shared and private assemblies is the fact that a single copy of a shared assembly can be used by several applications on a single machine. You cannot install executable assemblies (*.exe) into the GAC. Only assemblies that take the *.dll file extension can be deployed as a shared assembly.

<codeBase>  - Application configuration files can also specify code bases. The <codeBase> element can be used to instruct the CLR to probe for dependent assemblies located at arbitrary locations. If the value assigned to a <codeBase> element is located on a remote machine, the assembly will be downloaded on demand to a specific directory in the GAC termed the download cache. Given what you have learned about deploying assemblies to the GAC, it should make sense that assemblies loaded from a <codeBase> element will need to be assigned a strong name.

System.Configuration Namespace - The System.Configuration namespace provides a small set of types you may use to read custom data from a client’s *.config file. These custom settings must be contained within the scope of an <appSettings> element. The <appSettings> element contains any number of <add> elements that define a key/value pair to be obtained programmatically.

Machine Configuration File - The .NET platformmaintains a separate *.config file for each version of the framework installed on the local machine. If you were to open this file, you would find numerous XML elements that control ASP.NET settings, various security details, debugging support, and so forth. However, if you wish to update the machine.config file with machinewide application settings.