Assemblies - Part 2

Structure of an Assembly
A .NET assembly consists of assembly metadata and the assembly manifest contains the type information, resources, and the MSIL code to implement type metadata in an assembly. The manifest is an important component of an assembly. The assembly manifest contains the following:

- Identity Information: Identifies the assembly uniquely by the combination of four properties: assembly name, assembly version, culture, and strong name.
- File List Information: Includes types and declarations defined in another file. Every assembly is made up of one or more files. The manifest maintains a list of files that make up the assembly. The manifest maps the file containing the types and declarations to the file containing the declaration and implementation of an application.
- Referenced Assembly Information: Includes the information of references to other assemblies. In application development, you can develop various components that are spread across various assemblies.
- Exported Type References: Includes information about the functions and types that are exported and available to other assemblies. The components of other assemblies may refer to the methods and properties in the current assembly.
- Type Metadata: Provides the description of each class type. The manifest includes the name of each class type exported from the assembly and the information about the file containing its metadata.
- MSIL Code: Contains the compiled code in the MSIL format. The manifest is the system information about the assembly. The .NET platform compiles code written in a CLS-compliant language to an Intermediate Language (IL). The MSIL compiler compiles the source code to an IL form. When the .Net-based code is executed, the just-in-time compiler of the .NET runtime compiles the IL code to the executable form. The runtime loads the compiled code segment in memory and executes it. As a result, the system stores the complete compiled code as part of the assembly in IL format and recompiles and executes it. This happens only once between the loading and unloading of the .NET runtime.
- Resources: Includes resources such as bitmaps that you can integrate into a manifest. The assembly's resource section contains information on the resources the application uses.

Types of Assemblies

There are two types of assemblies, single-file and multi-file assemblies. In the .NET platform there is no difference between the two. Based on the structure, constraints, and requirements of the development team, you can choose either type of assembly.

Single-File Assembly
A single-file assembly stores the manifest, type metadata, IL, and resources in a single file. You can use this approach for simple applications when you need to develop an assembly for a small-scale deployment.

Multi-File Assembly
When developing large applications, you can split the application into smaller modules and deploy different development teams to work on various modules in a parallel mode. In this situation, you can use multi-file assemblies, with the different teams developing and compiling the modules. Using the assembly linker, you can integrate the modules into an application, where the assembly is broken into multiple files. Although the application environment contains several modules that can be developed by separate teams, the modules are closely related in functionality. For example, you can have different modules related to the system administration functionality, developed over a period of time. Using the multi-file assembly feature of .NET, you can group all administration functionality modules into an assembly to facilitate component versioning and maintenance.

Scope of Assemblies
Assemblies can either contain a private or a public scope, based on the level of access required by the clients who access it. The manifest contains information regarding the scope of an assembly.

Private Assembly
Assemblies are private in scope if only one application can access them. Private assemblies are only available to clients in the same directory structure as the assembly. As a result, the .NET assembly resides in the same directory structure as the client executable. You can use a private assembly when it is specific to a client application and no other client application refers to it.

Shared Assembly
When an assembly such as a system assembly contains features shared by various applications, standard deployment techniques discourage the use of private assemblies. As a result, you need to maintain a copy of the assembly for each client application. You can also register the assembly in the Global Assembly Cache (GAC), so that all client applications refer to one copy of the assembly. This type of assembly is called a shared assembly. The side-by-side execution feature of the .NET platform enables you to register multiple versions of the same assembly in GAC.

Global Assembly Cache
GAC is a repository of assemblies used by multiple applications on a system. When you install the .NET runtime on a system, it creates a cache, which can be used to store assemblies.

Advantages of Storing an Assembly in GAC
The advantages of storing an assembly as a shared assembly in GAC are:
- Multiple Applications: Allows you to access an assembly from one location, GAC. If multiple applications use the same assembly, instead of keeping a copy of the assembly in each application folder, you can store a shared assembly in GAC.
- Security: Ensures that only the system administrator can modify permissions of the folder. The GAC is always installed in the system folder. It inherits the permissions and Access Control Lists (ACLs) present in the system folder. As a result, you can protect GAC from unauthorized modifications.
- Side-by-side Versioning: Enables you to maintain multiple versions of the same application on a system. Private assemblies enable you to maintain a copy of the assembly in every client application folder. When a new version of an assembly is released, instead of updating the assemblies in all client applications, you can maintain multiple versions of the assembly in a central location, GAC. Client applications can refer to various versions of assemblies in GAC.
- Automatic Search Location: Enables the client application to easily access an assembly stored in GAC. When the runtime searches for an assembly, GAC is the default location it searches.

Disadvantage of Storing an Assembly in GAC
In a private assembly, you can use a simple Xcopy operation for deployment, which you cannot use for GAC-based assemblies. The assembly has to be physically registered in the GAC of client computers. For example, assemblies stored in the GAC should have the same assembly name and file name, which means that you should save assembly name abc as abc.exe or abc.dll.