Сборка в общеязыковой инфраструктуре (CLI), определенная Microsoft для использования в последних версиях Windows , представляет собой скомпилированную библиотеку кода, используемую для развертывания, управления версиями и обеспечения безопасности. Существует два типа: сборки процессов ( EXE ) и сборки библиотек ( DLL ). Сборка процесса представляет собой процесс, который будет использовать классы , определенные в сборках библиотек. Сборки CLI содержат код на CIL , который обычно генерируется из языка CLI , а затем компилируется в машинный язык во время выполнения с помощьюкомпилятор точно в срок . В реализации .NET Framework этот компилятор является частью среды Common Language Runtime (CLR).
Сборка может состоять из одного или нескольких файлов. Файлы кода называются модулями. Сборка может содержать более одного модуля кода. А поскольку для создания модулей кода можно использовать разные языки , технически возможно использовать несколько разных языков для создания сборки. Однако Visual Studio не поддерживает использование разных языков в одной сборке.
Маркер открытого ключа используется для того, чтобы сделать имя сборки уникальным. Таким образом, две сборки со строгим именем могут иметь одно и то же имя PE-файла, но CLI распознает их как разные сборки. Файловая система Windows ( FAT32 и NTFS ) распознает только имя PE-файла, поэтому две сборки с одинаковым именем PE-файла (но разными культурами, версией или токеном открытого ключа) не могут существовать в одной папке Windows. Чтобы решить эту проблему, CLI представляет GAC ( глобальный кэш сборок ), который во время выполнения рассматривается как отдельная папка, но на самом деле реализуется с использованием вложенных папок файловой системы.
Чтобы предотвратить спуфинговые атаки , когда взломщик пытается выдать сборку за что-то другое, сборка подписывается закрытым ключом. Разработчик предполагаемой сборки держит закрытый ключ в секрете, поэтому взломщик не может получить к нему доступ или просто угадать его. Таким образом, взломщик не может заставить свою сборку выдавать себя за что-то другое, не имея возможности правильно подписать ее после изменения. Подписание сборки включает получение хэша важных частей сборки и последующее шифрование .хэш с закрытым ключом. Подписанный хэш хранится в сборке вместе с открытым ключом. Открытый ключ расшифрует подписанный хэш. Когда CLR загружает сборку со строгим именем, она генерирует хэш из сборки, а затем сравнивает его с расшифрованным хэшем. Если сравнение прошло успешно, это означает, что открытый ключ в файле (и, следовательно, токен открытого ключа) связан с закрытым ключом, используемым для подписи сборки. Это будет означать, что открытый ключ в сборке является открытым ключом издателя сборки и, следовательно, предотвращается спуфинговая атака.
Сборки CLI могут иметь информацию о версии, что позволяет устранить большинство конфликтов между приложениями, вызванных общими сборками. [2] Однако это не устраняет все возможные конфликты версий между сборками. [3]
CLI Code Access Security основан на сборках и доказательствах . Свидетельством может быть что угодно, полученное из сборки, но обычно оно создается из источника сборки — независимо от того, была ли сборка загружена из Интернета, интрасети или установлена на локальном компьютере (если сборка загружена с другого компьютера, она будет храниться в изолированном месте в GAC и, следовательно, не считается установленным локально). Разрешения применяются ко всем сборкам, и сборка может указать минимальные разрешения, необходимые для нее, с помощью настраиваемых атрибутов (см. метаданные CLI). Когда сборка загружена, CLR будет использовать свидетельство сборки для создания набора разрешений, состоящего из одного или нескольких разрешений на доступ к коду. Затем CLR проверит, содержит ли этот набор разрешений необходимые разрешения, указанные сборкой.