Microsoft .Net Assembly

The Microsoft .NET Assembly stands as a coherent and logical entity comprising code that the Common Language Runtime (CLR) dutifully executes. It represents the fundamental and indivisible unit of deployment for a .NET application, assuming the form of either a dynamic-link library (.dll) or an executable (.exe) file. The Assembly serves as a consistent conglomeration of various types and resource information, carefully constructed to collaborate seamlessly and bestow a cohesive unit of functionality. It encompasses both executable application files, capable of direct execution within the Windows environment, without any external dependencies (.exe files), and libraries (.dll files), intended for utilization by other applications.

Assembly Manifest

Assemblies occupy a key role in the construction of .NET Framework applications. During the compilation process, Metadata is crafted in tandem with the Microsoft Intermediate Language (MSIL), subsequently bundled within a Portable Executable (PE) file. Crucially, the Assembly Manifest, nestled within this PE file, assumes the responsibility of documenting essential information about the Assembly itself. This encapsulated information, referred to as the Assembly Manifest, furnishes vital details pertaining to the Assembly's members, types, references, and other indispensable data indispensable for runtime execution.

Each Assembly created invariably comprises one or more program files, accompanied by a Manifest. These program files can be categorized into two distinct types: Process Assemblies (EXE) and Library Assemblies (DLL). It is important to note that each Assembly possesses a sole entry point, designated as DllMain, WinMain, or Main, which serves as the initial point of execution.

We can create two types of Assembly:

1. Private Assembly

2. Shared Assembly

Within the Assemblies, we encounter three distinct types: private Assembly, shared Assembly, and the lesser-known Satellite Assembly. A private Assembly finds purpose solely within a single application and is typically stored within the installation directory of said application. On the other hand, a shared Assembly is designed to be referenced by multiple applications, promoting code reuse and facilitating efficient collaboration. To enable multiple applications to access a shared Assembly seamlessly, it is advisable to incorporate the Assembly into the Global Assembly Cache (GAC), ensuring centralized accessibility.

In addition to private and shared Assemblies, there exists a third type known as the Satellite Assembly. This particular type serves a unique purpose, predominantly focusing on static objects such as images and various non-executable files that are indispensable to the functioning of an application. Satellite Assemblies play a crucial role in enabling the localization and internationalization of applications, allowing for the seamless integration of language-specific resources.

Conclusion

While private Assemblies confine their utility to a single application and reside within its installation directory, shared Assemblies cater to the needs of multiple applications and can be conveniently referenced. For shared Assemblies, it is recommended to include them in the Global Assembly Cache (GAC) to facilitate smooth accessibility. Finally, Satellite Assemblies embrace a specialized role, catering to non-executable resources vital to application functionality, especially those related to localization and internationalization.