Assembly (CLI)

An assembly in the Common Language Infrastructure (CLI) is a compiled code library used for deployment, versioning, and security. There are two types: process assemblies (EXE) and library assemblies (DLL). A process assembly represents a process that will use classes defined in library assemblies. CLI assemblies contain code in CIL, which is usually generated from a CLI language, and then compiled into machine language at run time by the just-in-time compiler. In the .NET Framework implementation, this compiler is part of the Common Language Runtime (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, it is technically possible to use several different languages to create an assembly. Visual Studio however does not support using different languages in one assembly.

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-bithash 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 the CLI 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, the CLI introduces the GAC (Global Assembly Cache) that is treated as a single folder by run-time, but is actually implemented using nested file system folders.

Para prevenir ataques de suplantación de identidad , en los que un atacante intentaría hacer pasar un ensamblado por otra cosa, este se firma con una clave privada. El desarrollador del ensamblado mantiene la clave privada en secreto, por lo que un atacante no puede acceder a ella ni adivinarla. De esta forma, el atacante no puede suplantar la identidad de otro ensamblado, ya que carece de la posibilidad de firmarlo correctamente después de la modificación. La firma del ensamblado implica generar un hash de las partes importantes del mismo y luego cifrarlo con la clave privada. El hash firmado se almacena en el ensamblado junto con la clave pública. La clave pública descifra el hash firmado. Cuando el CLR carga un ensamblado con nombre seguro, genera un hash a partir del ensamblado y lo compara con el hash descifrado. Si la comparación es exitosa, significa que la clave pública en el archivo (y, por lo tanto, el token de clave pública) está asociada con la clave privada utilizada para firmar el ensamblado. Esto significa que la clave pública en el ensamblado es la clave pública del editor del ensamblado y, por lo tanto, se previene un ataque de suplantación de identidad.

Los ensamblados CLI pueden tener información de versión, lo que permite eliminar la mayoría de los conflictos entre aplicaciones causados ​​por ensamblados compartidos. ^{[ 2 ]} Sin embargo, esto no elimina todos los posibles conflictos de versiones entre ensamblados. ^{[ 3 ]}

La seguridad de acceso al código de la CLI se basa en ensamblados y evidencia . La evidencia puede ser cualquier dato deducido del ensamblado, pero normalmente se crea a partir del origen del ensamblado, ya sea que se haya descargado de Internet, una intranet o se haya instalado en la máquina local (si el ensamblado se descarga de otra máquina, se almacenará en una ubicación aislada dentro de la GAC ​​y, por lo tanto, no se tratará como si estuviera instalado localmente). Los permisos se aplican a ensamblados completos, y un ensamblado puede especificar los permisos mínimos que requiere mediante atributos personalizados (consulte los metadatos de la CLI ). Cuando se carga el ensamblado, el CLR utilizará la evidencia del ensamblado para crear un conjunto de permisos de uno o más permisos de acceso al código. A continuación, el CLR comprobará que este conjunto de permisos contenga los permisos requeridos especificados por el ensamblado.

El código CLI puede realizar una comprobación de seguridad de acceso al código. Esto significa que el código solo realizará una acción privilegiada si todos los ensamblados de todos los métodos en la pila de llamadas tienen el permiso especificado. Si un ensamblado no tiene el permiso, se genera una excepción de seguridad.

El código CLI también puede realizar una solicitud vinculada para obtener el permiso de la pila de llamadas. En este caso, el CLR examinará únicamente un método en la posición superior de la pila de llamadas para el permiso especificado. Aquí, el recorrido de la pila se limita a un método en la pila de llamadas, por lo que el CLR asume que todos los demás métodos en la pila de llamadas tienen el permiso especificado. El ensamblado es una combinación de metadatos y un archivo MSIL.

En general, los ensamblados deben contener recursos independientes de la cultura. Si desea localizar su ensamblado (por ejemplo, usar diferentes cadenas para diferentes configuraciones regionales), debe usar ensamblados satélite: ensamblados especiales que solo contienen recursos. Como su nombre indica, un satélite está asociado a un ensamblado llamado ensamblado principal. Ese ensamblado (por ejemplo, lib.dll) contendrá los recursos neutrales (que Microsoft indica que son inglés internacional , pero que implican que son inglés estadounidense). Cada satélite tiene el nombre de la biblioteca asociada seguido de .resources (por ejemplo, lib.resources.dll). Al satélite se le asigna un nombre de cultura no neutral, pero dado que los sistemas de archivos de Windows existentes (FAT32 y NTFS) lo ignoran, esto significaría que podría haber varios archivos con el mismo nombre PE en una misma carpeta. Como esto no es posible, los satélites deben almacenarse en subcarpetas dentro de la carpeta de la aplicación. Por ejemplo, un satélite con los recursos en inglés del Reino Unido tendrá un nombre de CLI de "lib.resources Version=0.0.0.0 Culture=en-GB PublicKeyToken=null", un nombre de archivo PE de lib.resources.dll, y se almacenará en una subcarpeta llamada en-GB.

Los satélites se cargan mediante una clase CLI llamada System.Resources.ResourceManager. El desarrollador debe proporcionar el nombre del recurso e información sobre el ensamblado principal (con los recursos neutros). La clase ResourceManager leerá la configuración regional de la máquina y utilizará esta información y el nombre del ensamblado principal para obtener el nombre del satélite y el nombre de la subcarpeta que lo contiene. ResourceManagerLuego, puede cargar el satélite y obtener el recurso localizado.

Se puede hacer referencia a una biblioteca de código ejecutable utilizando la bandera /reference del compilador de C#.

Los ensamblados compartidos deben tener un nombre seguro para identificarlos de forma unívoca, ya que podrían ser compartidos entre aplicaciones. Este nombre seguro incluye el token de clave pública, la configuración regional, la versión y el nombre del archivo PE. Si un ensamblado compartido se va a utilizar para desarrollo, el procedimiento de nombre seguro solo incluye la generación de la clave pública. La clave privada no se genera en ese momento, sino únicamente cuando se implementa el ensamblado.

El ensamblado se construye con código CIL, que es un lenguaje intermedio. El framework convierte internamente el CIL ( bytecode ) en código ensamblador nativo . Si tenemos un programa que imprime "Hola Mundo", el código CIL equivalente para el método es:

. método privado hidebysig estático void Main ( string [] args ) cil managed { . entrypoint . custom instance void [ mscorlib ] System . STAThreadAttribute ::. ctor () = ( 01 00 00 00 ) // Tamaño del código 11 (0xb) . maxstack 1 IL_0000 : ldstr "Hello World" IL_0005 : call void [ mscorlib ] System . Console :: WriteLine ( string ) IL_000a : ret } // fin del método Class1::Main

El código CIL carga la cadena en la pila, luego llama a la función WriteLine y regresa.

• Manifiesto (CLI)