In the Microsoft .NET framework an assembly is a partially compiled code library for use in deployment, versioning and security. In the Microsoft Windows implementation of .NET, an assembly is a PE (portable executable) file. There are two types, process assemblies (EXE) and library assemblies (DLL). A process assembly represents a process which will use classes defined in library assemblies. In version 1.1 of the CLR classes can only be exported from library assemblies; in version 2.0 this restriction is relaxed. The compiler will have a switch to determine if the assembly is a process or library and will set a flag in the PE file. .NET does not use the extension to determine if the file is a process or library. This means that a library may have either .dll or .exe as its extension.
The code in an assembly is partially compiled into CIL, which is then fully compiled into machine language at runtime by the CLR.
An assembly can consist of one or more files. Code files are called modules. An assembly can contain more than one code module and since it is possible to use different languages to create code modules this means that it is technically possible to use several different languages to create an assembly. In practice this rarely happens, principally because Visual Studio only allows developers to create assemblies that consist of a single code module.
The name of an assembly consists of four parts:
1. The short name. On Windows this is the name of the 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 for 4 values — major, minor, build and revision. The version is only used if the assembly has a strong name (see below).
4. A public key token. This is a 64-bit hash of the public key which corresponds to the private key used to sign 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 recognise them as different assemblies. The Windows file system (FAT32 and NTFS) only recognises the PE filename, 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 something called the GAC (Global Assembly Cache) which is treated as a single folder by the .NET CLR, but is actually implemented using nested NTFS (or FAT32) folders.
To prevent spoofing attacks, where a cracker would try to pass off their assembly as yours, the assembly is signed with a private key. You keep your private key secret, so a cracker cannot have access to it, and cannot guess the associated public key. 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 compares 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 thwarted.
.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.