Assemblies Overview (.NET, C# )

Environment: C#, .NET

What is Assembly in .NET? An assembly is a file that is automatically generated by the compiler upon successful compilation of every .NET application. It can be either a Dynamic Link Library or an executable file. It is generated only once for an application and upon each subsequent compilation the assembly gets updated. The entire process will run in the background of your application; there is no need for you to learn deeply about assemblies. However, a basic knowledge about this topic will help you to understand the architecture behind a .NET application. An Assembly contains Intermediate Language (IL) code, which is similar to Java byte code. In the .NET language, it consists of metadata. Metadata enumerates the features of every "type" inside the assembly or the binary. In addition to metadata, assemblies also have a special file called Manifest. It contains information about the current version of the assembly and other related information. In .NET, there are two kinds of assemblies, such as Single file and Multi file. A single file assembly contains all the required information (IL, Metadata, and Manifest) in a single package. The majority of assemblies in .NET are made up of single file assemblies. Multi file assemblies are composed of numerous .NET binaries or modules and are generated for larger applications. One of the assemblies will contain a manifest and others will have IL and Metadata instructions. The main benefit of Intermediate Language is its power to integrate with all NET languages. This is because all .NET languages produce the same IL code upon successful compilation; hence, they can interact with each other very easily.

However, .NET is not yet declared as a platform-independent language; efforts are on at Microsoft to achieve this objective.

As of today, .NET applications are equipped to run only on Windows. An Assembly contains Intermediate Language (IL) code, which is similar to Java byte code. In the .NET language, it consists of metadata. Metadata enumerates the features of every "type" inside the assembly or the binary. In addition to metadata, assemblies also have a special file called Manifest. It contains information about the current version of the assembly and other related information. In .NET, there are two kinds of assemblies, such as Single file and Multi file. A single file assembly contains all the required information (IL, Metadata, and Manifest) in a single package. The majority of assemblies in .NET are made up of single file assemblies. Multi file assemblies are composed of numerous .NET binaries or modules and are generated for larger applications. One of the assemblies will contain a manifest and others will have IL and Metadata instructions. The main benefit of Intermediate Language is its power to integrate with all NET languages. This is because all .NET languages produce the same IL code upon successful compilation; hence, they can interact with each other very easily. However, .NET is not yet declared as a platform-independent language; efforts are on at Microsoft to achieve this objective. As of today, .NET applications are equipped to run only on Windows. An assembly is a fundamental building block of any .NET Framework application. For example, when you build a simple C# application, Visual Studio creates an assembly in the form of a single portable executable (PE) file, specifically an EXE or DLL. Assemblies contain metadata that describe their own internal version number and details of all the data and object types they contain. For more information see Assembly Manifest. Assemblies are only loaded as they are required. If they are not used, they are not loaded. This means that assemblies can be an efficient way to manage resources in larger projects. Assemblies can contain one or more modules. For example, larger projects may be planned in such a way that several individual developers work on separate modules, all coming together to create a single assembly. For more information on modules, see the topic How to: Build a Multifile Assembly. Assemblies have the following properties: Assemblies are implemented as .exe or .dll files. You can share an assembly between applications by placing it in the Global Assembly Cache. Assemblies must be strong-named before they can be placed in the Global Assembly Cache. For more information, see Strong-Named Assemblies. Assemblies are only loaded into memory if they are required. You can programmatically obtain information about an assembly using reflection. For more information, see the topic Reflection. If you want to load an assembly only to inspect it, use a method such as ReflectionOnlyLoadFrom. You can use two versions of the same assembly in a single application. For more information, see extern alias. Strong-Named Assemblies A strong name consists of the assembly's identity—its simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. It is generated from an assembly file (the file that contains the assembly manifest, which in turn contains the names and hashes of all the files that make up the assembly), using the corresponding private key. Microsoft® Visual Studio® .NET and other development tools provided in the .NET Framework SDK can assign strong names to an assembly. Assemblies with the same strong name are expected to be identical. You can ensure that a name is globally unique by signing an assembly with a strong name. In particular, strong names satisfy the following requirements: Strong names guarantee name uniqueness by relying on unique key pairs. No one can generate the same assembly name that you can, because an assembly generated with one private key has a different name than an assembly generated with another private key. Strong names protect the version lineage of an assembly. A strong name can ensure that no one can produce a subsequent version of your assembly. Users can be sure that a version of the assembly they are loading comes from the same publisher that created the version the application was built with. Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. Note, however, that strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate. When you reference a strong-named assembly, you expect to get certain benefits, such as versioning and naming protection. If the strong-named assembly then references an assembly with a simple name, which does not have these benefits, you lose the benefits you would derive from using a strong-named assembly and revert to DLL conflicts. Therefore, strong-named assemblies can only reference other strong-named assemblies.