Assemblies are of three types.
1. Private-The assembly that resides in the application 
directory and is only meant for that particular application.
2. Public/Shared-The assembly that is placed in the Global 
Assembly Cache where all the application can use the 
functionality of the assembly.
3. Satellite-An assembly that behaves differently for each 
application based on the culture information.

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.

.Net Assembly can be classified in four Categories:

  (A)  With Respect to  Program Access.
          i) Private Assembly- It can be used only in one
application.
         ii) Public/Shared Assembly- It can be used by all
applications in the server.

  (B)  With Respect to Number of Resources.
          i) Static Assembly- It uses fixed resources.
         ii) Dynamic Assembly- It supports dynamic creation
of resouces or files at    
             runtime programatically.

  (C) With Respect to Deployment.
         i) Satellite Assembly- Easily Deployable. (Visual
Studio 2005).
        ii) Resource-Only Assembly- In Visual Studio 2003.

  (D) With Respect to Number of Assemblies.
         i) Single File Assembly- /Bin/x.dll

        ii) Multi File Assembly- /Bin/x.dll
                                                   y.dll
                                                   z.dll  
                                                    ---
                                                    ---
                                                    ---