Язык программирования C#9 и платформа .NET5

  
Указание ссылок на внешние сборки в 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
:
 
// Наша сборка
.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
 в результате дает ошибку на этапе компиляции: