Concept of Assembly in DOT.NET

What is a .Net Assembly?

The .NET assembly is the standard for components developed with the Microsoft.NET. Dot NET assemblies may or may not be executable, i.e., they might exist as the executable (.exe) file or dynamic link library (DLL) file. All the .NET assemblies contain the definition of types, versioning information for the type, meta-data, and manifest. The designers of .NET have worked a lot on the component (assembly) resolution.

There are two kind of assemblies in .NET;

  • Private
  • Shared/Public

Private assemblies

Private assemblies are usually those assemblies that is going to be used by s single DOT.NET .  These assemblies are just copied in the same directory as that of application or in a sub directory.If you want to remove the application just delete the application folder. No fancy installation program is need to remove the application.

Shared assemblies

Also called strong named assemblies are copied to a single location (usually the Global assembly cache/GAC). These are usually those assemblies which are going to be used by multiple applications in that system .For all calling assemblies within the same application, the same copy of the shared assembly is used from its original location. Hence, shared assemblies are not copied in the private folders of each calling assembly. Each shared assembly has a four part name including its face name, version, public key token and culture information. The public key token and version information makes it almost impossible for two different assemblies with the same name or for two similar assemblies with different version to mix with each other.

An assembly can be a single file or it may consist of the multiple files. In case of multi-file, there is one master module containing the manifest while other assemblies exist as non-manifest modules. A module in .NET is a sub part of a multi-file .NET assembly. Assembly is one of the most interesting and extremely useful areas of .NET architecture along with reflections and attributes, but unfortunately very few people take interest in learning such theoretical looking topics.

Other terms related to assembly

Assembly names

The name of an assembly consists of four parts

  1. The short name. On Windows this is the name of the Portable Executable (PE) file without the extension.
  2. The culture. This is an RFC 1766 identifier of the locale for the assembly. In general, library and process assemblies should be culture neutral; the culture should only be used for satellite assemblies.
  3. The version. This is a dotted number made up of four values — major, minor, build and revision.
  4. A public key token. This is a 64-bit hash of the public key that corresponds to the private key used to sign[1] the assembly. A signed assembly is said to have a strong name.

The public key token is used to make the assembly name unique. Thus, two strong named assemblies can have the same PE file name and yet .NET will recognize them as different assemblies. The Windows file system (FAT32 and NTFS) only recognizes the PE file name, so two assemblies with the same PE file name (but different culture, version or public key token) cannot exist in the same Windows folder. To solve this issue .NET introduces the GAC (Global Assembly Cache) that is treated as a single folder by the .NET CLR, but is actually implemented using nested file system folders.

To prevent spoofing attacks, where a cracker would try to pass off an assembly appearing as something else, the assembly is signed with a private key. The developer of the intended assembly keeps the private key secret, so a cracker cannot have access to it nor simply guess it. Thus the cracker cannot make his assembly impersonate something else, lacking the possibility to sign it correctly after the change. Signing the assembly involves taking a hash of important parts of the assembly and then encrypting the hash with the private key. The signed hash is stored in the assembly along with the public key. The public key will decrypt the signed hash. When the CLR loads a strongly named assembly it will generate a hash from the assembly and then compare this with the decrypted hash. If the comparison succeeds then it means that the public key in the file (and hence the public key token) is associated with the private key used to sign the assembly. This will mean that the public key in the assembly is the public key of the assembly publisher and hence a spoofing attack is prevented.

Assemblies versions

.NET assemblies can have version information, allowing them to eliminate most conflicts between applications caused by shared assemblies.However, this does not eliminate all possible versioning conflicts between assemblies.

Assemblies and .NET security

.NET Code Access Security is based on assemblies and evidence. Evidence can be anything deduced from the assembly, but typically it is created from the source of the assembly — whether the assembly was downloaded from the Internet, an intranet, or installed on the local machine (if the assembly is downloaded from another machine it will be stored in a sandboxed location within the GAC and hence is not treated as being installed locally). Permissions are applied to entire assemblies, and an assembly can specify the minimum permissions it requires through custom attributes (see .NET metadata). When the assembly is loaded the CLR will use the evidence for the assembly to create a permission set of one or more code access permissions. The CLR will then check to make sure that this permission set contains the required permissions specified by the assembly.

.NET code can perform a code access security demand. This means that the code will perform some privileged action only if all of the assemblies of all of the methods in the call stack have the specified permission. If one assembly does not have the permission a security exception is thrown.

The .NET code can also perform Linked Demand for getting the permission from the call stack. In this case the CLR will look at only one method in the call stack in the TOP position for the specified permission. Here the stack walk-through is bound to one method in the call stack by which the CLR assumes that all the other methods in the CALL STACK have the specified permission. The Assembly is a combination of METADATA and MSIL file.

Satellite assemblies

In general, assemblies should contain culture-neutral resources. If you want to localize your assembly (for example use different strings for different locales) you should use satellite assemblies — special, resource-only assemblies. As the name suggests, a satellite is associated with an assembly called the main assembly. That assembly (say, lib.dll) will contain the neutral resources (that Microsoft says is International English, but implies to be US English). Each satellite has the name of the associated library appended with .resources (for example lib.resources.dll). The satellite is given a non-neutral culture name, but since this is ignored by existing Windows file systems (FAT32 and NTFS) this would mean that there could be several files with the same PE name in one folder. Since this is not possible, satellites must be stored in subfolders under the application folder. For example, a satellite with the UK English resources will have a .NET name of “lib.resources Version=0.0.0.0 Culture=en-GB PublicKeyToken=null”, a PE file name of lib.resources.dll, and will be stored in a subfolder called en-GB.

Satellites are loaded by a .NET class called System.Resources.ResourceManager. The developer has to provide the name of the resource and information about the main assembly (with the neutral resources). The ResourceManager class will read the locale of the machine and use this information and the name of the main assembly to get the name of the satellite and the name of the subfolder that contains it. ResourceManager can then load the satellite and obtain the localized resource.

Referencing assemblies

One can reference an executable code library by using the /reference flag of the C# compiler.

Delay-signing of an assembly

The shared assemblies need to give a strong name for uniquely identifying the assembly that might be shared among the applications. The strong naming consists of the public key token, culture, version and PE file name. If an assembly is likely to be used for the development purpose which is a shared assembly, the strong naming procedure contains only public key generation. The private key is not generated at that time. It is generated only when the assembly is deployed.

Language of an assembly

The assembly is built up with the CIL code, which is an intermediate language. The framework internally converts the CIL [bytecode] into native assembly code. If we have a program that prints “Hello World”, the equivalent CIL code for the method is:

.method private hidebysig static void  Main(string[] args) cil managed {
 .entrypoint
 .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
 // Code size       11 (0xb)
 .maxstack  1
 IL_0000:  ldstr      "Hello World"
 IL_0005:  call       void [mscorlib]System.Console::WriteLine(string)
 IL_000a:  ret } // end of method Class1::Main

So the CIL code loads the String onto the stack. Then it calls the WriteLine function and returns.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s