An assembly is a reusable, versionable, self-describing deployment unit for types and resources it is the primary building block of a .NET application. Assemblies provide the infrastructure to allow the runtime to fully understand the contents of an application and to enforce the versioning and dependency rules defined by the application.
An assembly consists of the following two logical elements: a)The sets of types and resources that form some logical unit of functionality. b) A manifest which is the metadata that describes how the types and resources relate and what they depend on to work properly.
Private assemblies are not designed to be shared. They are designed to be used by one application and must reside in that application's directory or subdirectory. This isolated methodology is nostalgically reminiscent of the DOS days when applications were fully contained within their own directories and did not disturb one another. By default, all assemblies (like the one we created in the previous example) are private. If you wish to make them shared, you must explicitly do so by signing them, as the upcoming example will illustrate. It is expected that the majority of assemblies you create will be of the private type.
2. Shared Assemblies:
For those components that must be distributed, Microsoft offers the shared assembly. The shared assembly concept is centered around two principles. The first, called side-by-side execution, allows the CLR to house multiple versions of the same component on a single machine. The second, termed binding, ensures that clients obtain the version of the component they expect. Together, these two principles free developers from having to ensure that their components are compatible with earlier versions. If a component evolves through versions 1.0, 1.1, and 2.0, the CLR will maintain separate copies of each version and invoke the correct one accordingly.
3. Satellite Assembly:
A satellite assembly is defined as an assembly with resources only, no executable code.