Язык программирования C#9 и платформа .NET5 - Троелсен Эндрю

На заметку! В окне свойств проекта Visual Studio корневое пространство имен по-прежнему представлено как стандартное (default). Далее вы увидите, почему в книге оно называется корневым (root) пространством имен.

Конфигурировать корневое пространство имен можно также путем редактирования файла проекта (

). Чтобы открыть файл проекта .NET Core, дважды щелкните на его имени в окне Solution Explorer или щелкните на нем правой кнопкой мыши и выберите в контекстном меню пункт Edit project file (Редактировать файл проекта). После открытия файла обновите главный узел , добавив узел :

Теперь, когда вы ознакомились с некоторыми деталями упаковки специальных типов в четко организованные пространства имен, давайте кратко рассмотрим преимущества и формат сборки .NET Core. Затем мы углубимся в подробности создания, развертывания и конфигурирования специальных библиотек классов.

Роль сборок .NET Core

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

или ), как и старые двоичные файлы Windows, в их внутренностях мало общего. Таким образом, первым делом давайте выясним, какие преимущества предлагает формат сборки.

Сборки содействуют многократному использованию кода

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

Возможно, вы уже знаете, что библиотека кода (также называемая библиотекой классов) — это файл

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

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

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

 Вспомните, что полностью заданное имя типа получается за счет предварения имени этого типа (

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

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

Сборкам .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 (

или ) состоит из следующих элементов:

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

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

• код CIL;

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

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

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