Assembly an
Introduction
An assembly is a small logical collection of classes that
contains the metadata of an application and components and resources that
enable you to create an application. An assembly is one of the main components
of the .NET framework and it is developed during the Runtime. An assembly
provides the CLR with the metadata, which describes types, members, and
references in your code. The runtime uses the metadata to locate and load
classes, lay out instances in memory, generate native code, and enforce security.
It contains a manifest for executing a Microsoft
Intermediate Language-based code (MSIL) at the CLR.Before the advent of the
.NET platform, the business logic was implemented in the COM component. The
main problem with COM is that it is tightly coupled with the operating system.
When you deploy a COM component on a system, it copies the related .dll or .exe
file to a specific location and makes an entry for the file in the registry. In
COM, every component is uniquely identified in the registry through a Globally
Unique Identifier (GUID).
DLL-hell Problem
COM-based systems are prone to the classic dll-hell problem.
You cannot modify a component after it is deployed without affecting existing
clients. COM provides a mechanism to register and access multiple versions of a
component in the registry, but the operating system does not provide a
mechanism to prevent an earlier version of a .dll from accidentally overwriting
a newer version.
Needs for Assemblies
The assembly handles the operating system dependency and DLL-hell problems because it is a self-describing unit. You can maintain two versions of the same assembly on the same system.
The assembly handles the operating system dependency and DLL-hell problems because it is a self-describing unit. You can maintain two versions of the same assembly on the same system.
COM-based systems are prone to the classic dll-hell problem.
You cannot modify a component after it is deployed without affecting existing
clients. COM provides a mechanism to register and access multiple versions of a
component in the registry, but the operating system does not provide a
mechanism to prevent an earlier version of a .dll from accidentally overwriting
a newer version.The assembly handles the operating system dependency and
DLL-hell problems because it is a self-describing unit. You can maintain two
versions of the same assembly on the same system.
When Microsoft developed the .NET platform, the operating
system dependency and the dll-hell problems were a major focus and it wanted to
remove the coupling between the platform and the registry. The metadata of an
application resides in the application itself and provides multiple versions of
applications on the same system because each version maintains its own
metadata.
- Easy Deployment: Allows you to deploy a .NET component on
a client computer with a simple Xcopy command.
- Side-by-side Execution: Allows other applications to use
assemblies in addition to the primary application.
- Operating System Independence: Allow you to port
assemblies to any operating system that supports a .NET common runtime
environment.
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.
- 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.
- 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.
- 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.
- 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.
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
Multi-File Assembly
Single-File Assembly
Multi-File 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: 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
•
Shared
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): 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
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.
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.
- 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.
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.
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.