Возможно, вы уже знаете, что библиотека кода (также называемая библиотекой классов) — это файл *.dll, который содержит типы, предназначенные для применения внешними приложениями. При построении исполняемых сборок вы без сомнения будете использовать много системных и специальных библиотек кода по мере создания приложений. Однако имейте в виду, что библиотека кода необязательно должна получать файловое расширение *.dll. Вполне допускается (хотя нечасто), чтобы исполняемая сборка работала с типами, определенными внутри внешнего исполняемого файла. В таком случае ссылаемый файл *.ехе также может считаться библиотекой кода.

Независимо от того, как упакована библиотека кода, платформа .NET Core позволяет многократно применять типы в независимой от языка манере. Например, вы могли бы создать библиотеку кода на C# и повторно использовать ее при написании кода на другом языке программирования .NET Core. Между языками есть возможность не только выделять память под экземпляры типов, но также и наследовать от самих типов. Базовый класс, определенный в С#, может быть расширен классом, написанным на Visual Basic. Интерфейсы, определенные в F#, могут быть реализованы структурами, определенными в С#, и т.д. Важно понимать, что за счет разбиения единственного монолитного исполняемого файла на несколько сборок .NET Core достигается возможность многократного использования кода в форме, нейтральной к языку.

Сборки устанавливают границы типов

 Вспомните, что полностью заданное имя типа получается за счет предварения имени этого типа (Console) названием пространства имен, где он определен (System). Тем не менее, выражаясь строго, удостоверение типа дополнительно устанавливается сборкой, в которой он находится. Например, если есть две уникально именованных сборки (MyCars.dll и YourCars.dll), которые определяют пространство имен (CarLibrary), содержащее класс по имени SportsCar, то в мире .NET Core такие типы SportsCar будут рассматриваться как уникальные.

Сборки являются единицами, поддерживающими версии

Сборкам .NET Core назначается состоящий из четырех частей числовой номер версии в форме <старший номер>.<младший номер>.<номер сборки>.<номер редакции>. (Если номер версии явно не указан, то сборке автоматически назначается версия 1.0.0.0 из-за стандартных настроек проекта в .NET Core.) Этот номер позволяет множеству версий той же самой сборки свободно сосуществовать на одной машине.

Сборки являются самоописательными

Сборки считаются самоописательными отчасти из-за того, что в своем манифесте содержат информацию обо всех внешних сборках, к которым они должны иметь доступ для корректного функционирования. Вспомните из главы 1, что манифест представляет собой блок метаданных, которые описывают саму сборку (имя, версия, обязательные внешние сборки и т.д.).

В дополнение к данным манифеста сборка содержит метаданные, которые описывают структуру каждого содержащегося в ней типа (имена членов, реализуемые интерфейсы, базовые классы, конструкторы и т.п.). Благодаря тому, что сборка настолько детально документирована, среда .NET Core Runtime не нуждается в обращении к реестру Windows для выяснения ее местонахождения (что радикально отличается от унаследованной модели программирования СОМ от Microsoft). Такое отделение от реестра является одним из факторов, которые позволяют приложениям .NET Core функционировать под управлением других операционных систем (ОС) помимо Windows, а также обеспечивают поддержку на одной машине множества версий платформы .NET Core.

В текущей главе вы узнаете, что для получения информации о местонахождении внешних библиотек кода среда .NET Core Runtime применяет совершенно новую схему.

Формат сборки .NET Core

Теперь, когда вы узнали о многих преимуществах сборок .NET Core, давайте более детально рассмотрим, как такие сборки устроены внутри. Говоря о структуре, сборка .NET Core (*.dll или *.ехе) состоит из следующих элементов:

• заголовок файла ОС (например, Windows);

• заголовок файла CLR;

• код CIL;

• метаданные типов;

• манифест сборки;

• дополнительные встроенные ресурсы.

Несмотря на то что первые два элемента (заголовки ОС и CLR) представляют собой блоки данных, которые обычно можно игнорировать, краткого рассмотрения они все же заслуживают. Ниже приведен обзор всех перечисленных элементов.

Установка инструментов профилирования C++