Assemblies and the Assembly Loader……..
An assembly is a discrete unit of reusable code within the CLR, similar in nature to a DLL in the unmanaged world, but that’s where the similarities end. An assembly can consist of multiple modules all linked together by a manifest, which describes the contents of the assembly. With respect to the operating system, a module is identical to a DLL. Assemblies can have a version attached to them so that multiple assemblies with the same name but different versions are identifiable separately.
Assemblies also contain metadata describing the contained types. When you distribute a native DLL, you typically include a header file and/or documentation describing the exported functions. Metadata fulfills this requirement, completely describing the types contained within the assembly. In short, assemblies are versioned, self-describing units of reuse within the CLR environment.
As discussed in the previous chapter, when you compile the “Hello World!” program, the result is an .exe file that is, in fact, an assembly. You can create managed assemblies using any managed language. Moreover, in most cases, any other managed language can consume managed assemblies.
Therefore, you can easily create complex systems developed with multiple managed languages. For example, when creating some low-level types, C++ /CLI may be the most natural languages to get the job done, but it may make more sense to code the top-level user interface using either C# or Visual Basic. To provide interoperability between the various languages, the CLI defines a subset of the type system known as the Common Language Specification (CLS). If you use only CLS-compliant types in your assemblies, you are guaranteed that any managed language can consume them.
SHARE THE KNOWLEDGE