The Structure of a .NET Application

To understand how the common language run time manages the execution of code, we must examine the structure of a .NET application. The primary unit of a .NET application is the assembly. An assembly is a self-describing collection of code, resources, and metadata. The assembly manifest contains information about what is contained within the assembly. The assembly manifest provides
• Identity information, such as the name and version number of the assembly.
• A list of all types exposed by the assembly.
• A list of other assemblies required by the assembly.
• A list of code access security instructions for the assembly. This includes a list of permissions required by the assembly and permissions to be denied the assembly.

Each assembly has one and only one assembly manifest, and it contains all the description information for the assembly. The assembly manifest can be contained in its own separate file, or it can be contained within one of the assembly's modules.
An assembly also contains one or more modules. A module contains the code that makes up our application or library, and metadata that describes that code. When we compile a project into an assembly, our code is converted from high-level code to IL. Because all managed code is first converted to IL code, applications written in different languages can easily interact. For example, one developer might write an application in Visual C# that accesses a DLL in Visual Basic .NET. Both resources will be converted to IL modules before being executed, thus avoiding any language incompatibility issues.
Each module also contains a number of types. Types are templates that describe a set of data encapsulation and functionality. There are two kinds of types: reference types (classes) and value types (structures).Each type is described to the common language run time in the assembly manifest. A type can contain fields, properties, and methods, each of which should be related to a common functionality. For example, we might have a class that represents a bank account. It would contain fields, properties, and methods related to the functions needed to implement a bank account. A field represents storage of a particular type of data. We might have a field that stores the name of an account holder. Properties are similar to fields, but usually provide some kind of validation when the data is set or retrieved. We might have a property that represents the balance available in an account. When an attempt is made to change the value, the property could check to see if the attempted change was greater than a predetermined limit, and if so, could disallow the change. Methods represent behavior, such as actions taken on data stored within the class or changes to the user interface. Continuing with the bank account example, we might have a Transfer method that transfers a balance from a checking account to a savings account, or an Alert method that warns the user when his balance has fallen below a predetermined level.