Elements of a .NET Application

A .NET application is composed of four primary entities:

• Classes - The basic units that encapsulate data and behavior

• Modules - The individual files that contain the IL for an assembly

• Assemblies - The primary unit of deployment of a .NET application

• Types - The common unit of transmitting data between modules

Classes are covered in the preceding two chapters and are defined in the source files for your application or class library. Upon compilation of your source files, you produce a module. The code that makes up an assembly’s modules may exist in a single executable (.exe) file or as a dynamic link library (.dll). A module is in fact a Microsoft Intermediate Language file, which is then used by the CLR when your application is run. However, compiling a .NET application doesn’t produce only an MSIL file; it also produces a collection of files that make up a deployable application or assembly. Within an assembly, you will find several different types of files, including not only the actual executable files, but also configuration files, signature keys, and most important of all, the actual code modules.

Modules

A module contains Microsoft Intermediate Language (MSIL, often abbreviated to IL) code, associated metadata, and the assembly’s manifest. By default, the Visual Basic compiler creates an assembly that is composed of a single module having both the assembly code and manifest.

IL is a platform-independent way of representing managed code within a module. Before IL can be executed, the CLR must compile it into the native machine code. The default method is for the CLR to use the JIT (Just-in-Time) compiler to compile the IL on a method-by-method basis. At runtime, as each method is called by an application for the first time, it is passed through the JIT compiler for compilation to machine code. Similarly, for an ASP.NET application, each page is passed through the JIT compiler the first time it is requested, to create an in-memory representation of the machine code that represents that page.

Additional information about the types declared in the IL is provided by the associated metadata. The metadata contained within the module is used extensively by the CLR. For example, if a client and an object reside within two different processes, then the CLR will use the type’s metadata to marshal data between the client and the object. MSIL is important because every .NET language compiles down to IL. The CLR doesn’t care or need to know what the implementation language was; it knows only what the IL contains. Thus, any differences in .NET languages exist at the level where the IL is generated; but once generated, all .NET languages have the same runtime characteristics. Similarly, because the CLR doesn’t care in which language a given module was originally written, it can leverage modules implemented in entirely different .NET languages.

A question that continually arises when discussing the JIT compiler and the use of a runtime environment is: “Wouldn’t it be faster to compile the IL language down to native code before the user asks to run it?” Although the answer is not always yes, Microsoft has provided a utility to handle this compilation: Ngen.exe. Ngen (short for native image generator) enables you to essentially run the JIT compiler on a specific assembly, and this assembly is then installed into the user’s application cache in its native format. The obvious advantage is that now when the user asks to execute something in that assembly, the JIT compiler is not invoked, saving a small amount of time. However, unlike the JIT compiler, which only compiles those portions of an assembly that are actually referenced, Ngen.exe needs to compile the entire codebase, so the time required for compilation is not the same as what a user actually experiences.

Ngen.exe is executed from the command line. The utility was updated as part of .NET 2.0 and now automatically detects and includes most of the dependent assemblies as part of the image generation process. To use Ngen.exe, you simply reference this utility followed by an action; for example, install followed by your assembly reference. Several options are available as part of the generation process, but they go beyond the scope of this chapter, given that Ngen.exe itself is a topic that can generate heated debate regarding its use and value.

So where does the debate begin about when to use Ngen.exe? Keep in mind that in a server application, where the same assembly will be referenced by multiple users between machine restarts, the difference in performance on the first request is essentially lost. This means that compilation to native code is more valuable to client-side applications. Unfortunately, using Ngen.exe requires running it on each client machine, which can become cost-prohibitive in certain installation scenarios, particularly if you use any form of self-updating application logic. Another issue relates to using reflection, which enables you to reference other assemblies at runtime. Of course, if you don’t know what assemblies you will reference until runtime, then the native image generator has a problem, as it won’t know what to reference either. You may have occasion to use Ngen.exe for an application you’ve created, but you should fully investigate this utility and its advantages and disadvantages beforehand, keeping in mind that even native images execute within the CLR. Native image generation only changes the compilation model, not the runtime environment.

Assemblies

An assembly is the primary unit of deployment for .NET applications. It is either a dynamic link library (.dll) or an executable (.exe). An assembly is composed of a manifest, one or more modules, and (optionally) other files, such as .config, .ASPX, .ASMX, images, and so on.

The manifest of an assembly contains the following:

• Information about the identity of the assembly, including its textual name and version number

• If the assembly is public, then the manifest will contain the assembly’s public key. The public key is used to help ensure that types exposed by the assembly reside within a unique name-space. It may also be used to uniquely identify the source of an assembly.

• A declarative security request that describes the assembly’s security requirements (the assembly is responsible for declaring the security it requires). Requests for permissions fall into three categories: required, optional, and denied. The identity information may be used as evidence by the CLR in determining whether or not to approve security requests.

• A list of other assemblies that the assembly depends on. The CLR uses this information to locate an appropriate version of the required assemblies at runtime. The list of dependencies also includes the exact version number of each assembly at the time the assembly was created.

• A list of all types and resources exposed by the assembly. If any of the resources exposed by the assembly are localized, the manifest will also contain the default culture (language, currency, date/time format, and so on) that the application will target. The CLR uses this information to locate specific resources and types within the assembly.

The manifest can be stored in a separate file or in one of the modules, but by default for most applications, it is part of the .dll or .exe file, which is compiled by Visual Studio. For Web applications, you will find that although there is a collection of ASPX pages, the actual assembly information is located in a DLL referenced by those ASPX pages.

Types

The type system provides a template that is used to describe the encapsulation of data and an associated set of behaviors. It is this common template for describing data that provides the basis for the metadata that .NET uses when applications interoperate. There are two kinds of types: reference and value. The differences between these two types are discussed in Chapter 2.

Unlike COM, which is scoped at the machine level, types are scoped at either the global or the assembly level. All types are based on a common system that is used across all .NET languages. Similar to the MSIL code, which is interpreted by the CLR based upon the current runtime environment, the CLR uses a common metadata system to recognize the details of each type. The result is that all .NET languages are built around a common type system, unlike the different implementations of COM, which require special notation to allow translation of different datatypes between different .exe and .dll files.

A type has fields, properties, and methods:

• Fields - Variables that are scoped to the type. For example, a Pet class could declare a field called Name that holds the pet’s name. In a well-engineered class, fields are often kept private and exposed only as properties or methods.

• Properties - These look like fields to clients of the type, but can have code behind them (which usually performs some sort of data validation). For example, a Dog datatype could expose a property to set its gender. Code could then be placed behind the property so that it could be set only to “male” or “female,” and then this property could be saved internally to one of the fields in the dog class.

• Methods - Define behaviors exhibited by the type. For example, the Dog datatype could expose a method called Sleep, which would suspend the activity of the Dog.

The preceding elements make up each application. Note that this description mentions that some types are defined at the application level and others globally. Under COM, all components are registered globally, and certainly if you want to expose a .NET component to COM, you must register it globally. However, with .NET it is not only possible but often encouraged that the classes and types defined in your modules be only visible at the application level. The advantage of this is that you can run several different versions of an application side by side. Of course, once you have an application that can be versioned, the next challenge is knowing which version of that application you have.