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

    1 флаги

        Только IL

    0 маркер записи

    0 [   0] RVA [size] каталога Resources

    0 [   0] RVA [size] каталога StrongNameSignature

    0 [   0] RVA [size] каталога CodeManagerTable

    0 [   0] RVA [size] каталога VTableFixups

    0 [   0] RVA [size] каталога ExportAddressTableJumps

    0 [   0] RVA [size] каталога ManagedNativeHeader

  Сводка

        2000 .reloc

        2000 .rsrc

        2000 .text

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

Код CIL, метаданные типов и манифест сборки

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

Сборка также содержит метаданные, полностью описывающие формат внутренних типов и формат внешних типов, на которые сборка ссылается. Исполняющая среда .NET Core применяет эти метаданные для выяснения местоположения типов (и их членов) внутри двоичного файла, для размещения типов в памяти и для упрощения удаленного вызова методов. Более подробно детали формата метаданных .NET Core будут раскрыты в главе 17 во время исследования служб рефлексии.

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

Дополнительные ресурсы сборки

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

Отличия между библиотеками классов и консольными приложениями

До сих пор в этой книге почти все примеры были консольными приложениями .NET Core. При наличии опыта разработки для .NET, вы заметите, что они похожи на консольные приложения .NET. Основное отличие касается процесса конфигурирования (рассматривается позже), а также того, что они выполняются под управлением .NET Core. Консольные приложения имеют единственную точку входа (либо указанный метод Main(), либо операторы верхнего уровня), способны взаимодействовать с консолью и могут запускаться прямо из среды ОС. Еще одно отличие между консольными приложениями .NET Core и .NET связано с тем, что консольные приложения в .NET Core запускаются с применением хоста приложений .NET Core (dotnet.exe).

(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})

С другой стороны, библиотеки классов не имеют точки входа и потому не могут запускаться напрямую. Они используются для инкапсуляции логики, специальных типов и т.п., а ссылка на них производится из других библиотек классов и/или консольных приложений. Другими словами, библиотеки классов применяются для хранения всего того, о чем шла речь в разделе "Роль сборок .NET Core" ранее в главе.

Отличия между библиотеками классов .NET Standard и .NET Core

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

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

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

В каждой версии .NET Standard определен общий набор API-интерфейсов, которые должны поддерживаться всеми версиями .NET (.NET, .NET Core, Xamarin и т.д.), чтобы удовлетворять требованиям стандарта. Например, если бы вы строили библиотеку классов как проект .NET Standard 2.0, то на нее можно было бы ссылаться из .NET 4.6 .1+ и .NET Core 2.0+ (плюс разнообразные версии Xamarin, Mono, Universal Windows Platform и Unity).

Это означает, что вы могли бы перенести код из своих библиотек классов .NET в библиотеки классов .NET Standard 2.0 и совместно использовать их в приложениях .NET Core и .NET Такое решение гораздо лучше, чем поддержка двух копий того же самого кода, по одной для каждой платформы.

А теперь собственно о загвоздке. Каждая версия .NET Standard представляет собой наименьший общий знаменатель для платформ, которые она поддерживает, т.е. чем ниже версия, тем меньше вы можете делать в своей библиотеке классов.

Хотя в .NET (Core) 5 и .NET Core 3.1 можно ссылаться на библиотеку .NET Standard 2.0, в такой библиотеке вам не удастся задействовать существенное количество функциональных средств C# 8.0 (или любых средств C# 9.0). Для полной поддержки C# 8.0 и C# 9.0 вы должны применять .NET Standard 2.1, a .NET Standard 2.0 подходит только для .NET 4.8 (самая поздняя/последняя версия первоначальной инфраструктуры .NET Framework).