Указание ссылок на внешние сборки в CIL
Скопируйте файлы global.json и NuGet.config из предыдущего примера в новый каталог проекта. Создайте новый файл проекта по имени CILTypes.ilproj, содержимое которого показано ниже:
<Project Sdk="Microsoft.NET.Sdk.IL">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<MicrosoftNetCoreIlasmPackageVersion>
5.0.0-preview.1.20120.5
</MicrosoftNetCoreIlasmPackageVersion>
<ProduceReferenceAssembly>false</ProduceReferenceAssembly>
</PropertyGroup>
</Project>
Затем создайте в текстовом редакторе новый файл по имени CILTypes.il. Первой задачей в проекте CIL является перечисление внешних сборок, которые будут задействованы текущей сборкой. В рассматриваемом примере применяются только типы, находящиеся внутри сборки System.Runtime.dll. В новом файле понадобится указать директиву .assembly с уточняющим атрибутом external. При добавлении ссылки на сборку со строгим именем, подобную System.Runtime.dll, также должны быть указаны директивы .publickeytoken и .ver:
.assembly extern System.Runtime
{
.publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )
.ver 5:0:0:0
}
Определение текущей сборки в CIL
Следующее действие заключается в определении создаваемой сборки с использованием директивы .assembly. В простейшем случае сборка может быть определена за счет указания дружественного имени двоичного файла:
<b>// Наша сборка.</b>
.assembly CILTypes{}
Хотя такой код действительно определяет новую сборку .NET Core, обычно внутрь объявления будут помещаться дополнительные директивы. В рассматриваемом примере определение сборки необходимо снабдить номером версии 1.0.0.0 посредством директивы .ver (обратите внимание, что числа в номере версии отделяются друг от друга двоеточиями, а не точками, как принято в С#):
<b>// Наша сборка.</b>
.assembly CILTypes
{
<b> .ver 1:0:0:0</b>
}
Из-за того, что сборка CILTypes является однофайловой, ее определение завершается с применением следующей директивы .module, которая обозначает официальное имя двоичного файла .NET Core, т.е. CILTypes.dll:
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
// Наша сборка
.assembly CILTypes
{
.ver 1:0:0:0
}
// Модуль нашей однофайловой сборки.
.module CILTypes.dll
Кроме .assembly и .module существуют директивы CIL, которые позволяют дополнительно уточнять общую структуру создаваемого двоичного файла .NET Core. В табл. 19.1 перечислены некоторые наиболее распространенные директивы уровня сборки.
![]()
Определение пространств имен в CIL
Определив внешний вид и поведение сборки (а также обязательные внешние ссылки), вы можете создать пространство имен .NET Core (MyNamespace), используя директиву .namespace:
<b>// Наша сборка имеет единственное пространство имен.</b>
.namespace MyNamespace {}
Подобно C# определения пространств имен CIL могут быть вложены в другие пространства имен. Хотя здесь нет нужды определять корневое пространство имен, ради интереса посмотрим, как создать корневое пространство имен MyCompany:
.namespace MyCompany
{
.namespace MyNamespace {}
}
Как и С#, язык CIL позволяет определить вложенное пространство имен следующим образом:
<b>// Определение вложенного пространства имен.</b>
.namespace MyCompany.MyNamespace {}
Определение типов классов в CIL
Пустые пространства имен не особо интересны, поэтому давайте рассмотрим процесс определения типов классов в CIL. Для определения нового типа класса предназначена директива .class. Тем не менее, эта простая директива может быть декорирована многочисленными дополнительными атрибутами, уточняющими природу типа. В целях иллюстрации добавим в наше пространство имен открытый класс под названием MyBaseClass. Как и в С#, если базовый класс явно не указан, то тип автоматически становится производным от System.Object:
.namespace MyNamespace
{
<b> // Предполагается базовый класс System.Object.</b>
.class public MyBaseClass {}
}
При построении типа, производного не от класса System.Object, применяется атрибут extends. Для ссылки на тип, определенный внутри той же самой сборки, язык CIL требует использования полностью заданного имени (однако если базовый тип находится внутри той же самой сборки, то префикс в виде дружественного имени сборки можно не указывать). Следовательно, демонстрируемая ниже попытка расширения MyBaseClass в результате дает ошибку на этапе компиляции:
