If you like this article, please click on “+1“ button and share with your friends.

Click here for the Video Tutorial of this article.
visit www.iGnani.com

…previous article “C# 4.0 – Ch:01:D – Garbage Collector & Security in .NET”

What are assemblies?

An assembly is the .NET term for a deployment and configuration unit, which contains compiled code targeted at the .NET Framework and can be either an EXE or a DLL. For both EXE and DLL (executable code and library code), same assembly structure is used. The only real difference is that, while an EXE contains a main program entry point, a DLL does not.

Assemblies are logical rather than a physical unit, which means that it can be stored across more than one file. If an assembly is stored in more than one file, there will be one main file that contains the entry point and describes the other files in the assembly.

Assemblies can have a version attached to them so that multiple assemblies with the same name but different versions are identifiable separately, which we will see in the Shared Assembly section.

An assembly is a separate unit of reusable code, similar to a DLL in the unmanaged world, however that’s where the comparisons end. Even though they both have the same file extension as an EXE or DLL, .NET assemblies consist of multiple modules all linked together by a manifest, which describes the contents of the assembly. Assemblies contain metadata that describes the content of the assembly. Metadata covers all the types that are defined in an assembly with information about its members namely methods, properties, events, and fields.

Assemblies are self-describing. In other words, an assembly metadata contains data about the assembly itself. This data provides information about the files that belong to the assembly, version information, and the exact information about assemblies that are used and allows checks to be made on the version of the assembly, and on its integrity.

By having the metadata about the assembly in itself, applications or other assemblies that use these assemblies need not to refer to the registry, or to any other data source, to find out how to use that assembly. This marks an important change from the old COM way of doing things, in which the GUIDs of the components and interfaces were obtained from the registry and in certain cases, the details of the methods and properties exposed, had to be read from a type library.

Since all the metadata is stored in the assembly, even when assemblies are stored across several files, we need not worry about the problem of data going out of synchronization. The reason being that the file containing the assembly entry point also stores details of, and a hash of, the contents of the other files, which mean that if one of the files gets replaced, or in any way tampered with, this will almost certainly be detected and the assembly will not load.

Assemblies are of two types: private and shared assemblies.

Private assemblies

Private assemblies are the common and simplest type, which normally goes with the software and are intended to be used only with that software. To speak of a common scenario using private assemblies is when you are supplying an application containing an executable and one or more libraries, where in the libraries contain code that should be used with that application.

While we can be sure that that private assemblies will not be used by other software since an application may load only private assemblies that are located in the same folder as that of the main executable or in its subfolder. However, this does not mean that these private assemblies cannot be used by a different executable.

In all common scenarios a software would always be installed in its own directory, hence there is no risk of one software package overwriting, modifying, or accidentally loading private assemblies intended for another package.

Since an assembly is entirely self-contained, we can deploy them just by copying them into the appropriate folder in the file system, commonly known as xcopy installation.

Shared assemblies

Unlike private assemblies, Shared assemblies are intended to be common libraries that can be used by one or more applications. Hence we need to be more careful to avoid the situations like Name collisions, where a shared assembly from a different vendor implements types that have the same names as those in your shared assembly. Not just that, with assemblies having same name from the same vendor but with a different version and having incompatible code with the other, it can be overwritten.

We can overcome these situations by installing the assembly into the GAC. Each computer where the CLR is installed has a machine-wide code cache called the global assembly cache (GAC). GAC stores assemblies specifically designated to be shared by several applications on the computer.

In contrast to private assemblies, we cannot simply copy the assembly into the appropriate folder but needs to be specifically installed into the GAC. We can deploy an assembly into the GAC by

Using an installer designed to work with the global assembly cache. This is the preferred option for installing assemblies into the global assembly cache.
Using the developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the Windows Software Development Kit (SDK).
Use Windows Explorer to simply drag and drop the assemblies from any folder into the GAC.

Strong Naming

Unlike private assemblies which are simply given the same name as their main file name, shared assemblies are given a name based on private key cryptography to prevent name collisions. This name is known as a strong name.

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.

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.

This does not mean that the 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.

This should be sufficient for you as an introduction to .NET framework before starting with C#.NET programming. Assemblies are covered in details in the coming chapters, where in I will be covering them with examples.

….next article “C# 4.0 – Ch:02:A – Language Basics”

If you like this article, please click on “+1“ button and share with your friends.

visit www.iGnani.com

MicroMind Information Systems
#4013, K.R. Road, Banashankari II Stage,
BANGALORE - 560070
KARNATAKA, INDIA
Phone: +91 80 26762747