Microsoft provides a set of Just-in-Time (JIT) compilers for each supported platform. These compilers compile MSIL code into native machine code, so the JIT compiler is no longer needed to run the component. The compilation results in slower method calls the first time the code is run. However, it is compiled to native machine code, the code performs faster. The JIT compiles the code to machine code that is specific to the processor running the code. This offers a considerable performance advantage.
Note Unlike previous Microsoft compilers, the JIT compilers only compile methods that are being used. The code can be executed more quickly because this reduces the time that is needed to compile the MSIL code.
Assembly
The assembly is a collection of one or more files that maintain a developer's code and all the information that is required by the CLR execution environment. The assembly is the unit of deployment that is used to install a .NET application, including all resource files required by the application. These files can be bitmaps, JPEGs, and any other file type that is required by the application.
Note that applications may have more than one assembly. Every unit or application building block will have at least one assembly, but many applications require several building blocks. This is perfectly acceptable as assemblies can be configured to communicate with each other and take advantage of code in the other assemblies.
Assemblies can also be designated as "private" or "shared." A private assembly can be used by only one application and must be stored in the same directory or in a subdirectory of the calling application. Other assemblies can use a shared assembly that can only be updated by the author, making version control safer and malicious hacking more difficult. Usually a shared assembly is installed in the global assembly cache (discussed later in this chapter), which is a local cache of assemblies.
The Manifest
Part of the assembly includes a manifest which holds information about the assembly. This self-describing method of the assembly allows for easy deployment through the use of the XCOPY command from the command line prompt. Historically, this type of metadata was stored in the Windows Registry and required the registration of every COM (Common Object Model) component. This is no longer necessary because the information is stored exclusively in the assembly manifest.
Note The manifest can be stored in a separate file or as part of a module, such as an .EXE (executable) file or DLL (dynamic link library).
Among the information that is stored in the manifest is the name and version of the assembly. This is essential when an application is dependant on a specific version of an assembly. All other assemblies that depend on the assembly are stored in the manifest and help to determine if all required code for the application is available. To allow other components to
communicate with the assembly, all of the assembly's data types are described in the manifest. Additional security information for the assembly is also described by the manifest and
includes three possible security settings and the assembly public key, which guarantees uniqueness of the assembly and identifies the source of the assembly. The possible security settings are
• Required security. • Optional security. • Denied security settings.
Providing the ability to store all metadata within the assembly has an additional benefit. Because .NET assemblies no longer require a special installation to record metadata about the assembly in the Windows Registry, you can simply copy all .NET assemblies to a given location and run them. As a result, .NET assemblies can be run directly from a CD-ROM that, by its very nature, is readonly. This also means that complex installation programs are no longer needed. You can simply write a program that installs your .NET application and run it when the CD-ROM is inserted into the CD-ROM tray.
The metadata that is stored in the manifest is fully accessible through the use of the Reflection API. By using this API, the metadata can be extracted into XML format.
Assembly Versioning
Assemblies simplify versioning and interface development, allowing developers to determine the versioning rules by specifying the version the assembly is allowed to use.
Interface development in COM required that all assemblies maintain backward compatibility when upgrading an assembly to support new features; COM allowed only a single version of an assembly to be registered with the operating system at any given time. .NET assemblies, however, are not specific to a machine but specific to an assembly, allowing the installation of multiple versions of the same assembly on the same physical computer. When a .NET
assembly is upgraded, the older assembly can remain installed to maintain backwards compatibility for applications that are still using it.
Global Assembly Cache
Assemblies that are designated as "shared" are stored in the Global Assembly Cache. These assemblies are accessible by multiple applications on the computer. (Installing assemblies in the Global Assembly Cache requires administrative privileges to the machine where the assemblies are installed.)
Assemblies that are installed in the Global Assembly Cache are similar to COM components; the components cannot be accessed except through a single controlling force. In the case of assemblies, this is the Global Assembly Cache, whereas in COM it was the Windows registry.