сборки
Наконец, сборка .NET Core может содержать любое количество встроенных ресурсов, таких как значки приложения, файлы изображений, звуковые клипы или таблицы строк. На самом деле платформа .NET Core поддерживает подчиненные сборки, которые содержат только локализованные ресурсы и ничего другого. Они могут быть удобны, когда необходимо отделять ресурсы на основе культуры (русской, немецкой, английской и т.д.) при построении интернационального программного обеспечения. Тема создания подчиненных сборок выходит за рамки настоящей книги; если вам интересно, обращайтесь за информацией о подчиненных сборках и локализации в документацию по .NET Core.
Отличия между библиотеками классов и консольными приложениями
До сих пор в этой книге почти все примеры были консольными приложениями .NET Core. При наличии опыта разработки для .NET, вы заметите, что они похожи на консольные приложения .NET. Основное отличие касается процесса конфигурирования (рассматривается позже), а также того, что они выполняются под управлением .NET Core. Консольные приложения имеют единственную точку входа (либо указанный метод Main(), либо операторы верхнего уровня), способны взаимодействовать с консолью и могут запускаться прямо из среды ОС. Еще одно отличие между консольными приложениями .NET Core и .NET связано с тем, что консольные приложения в .NET Core запускаются с применением хоста приложений .NET Core (dotnet.exe).
С другой стороны, библиотеки классов не имеют точки входа и потому не могут запускаться напрямую. Они используются для инкапсуляции логики, специальных типов и т.п., а ссылка на них производится из других библиотек классов и/или консольных приложений. Другими словами, библиотеки классов применяются для хранения всего того, о чем шла речь в разделе "Роль сборок .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).
Итак, .NET Standard — все еще хороший механизм для использования существующего кода в более новых приложениях, но он не является панацеей.
Конфигурирование приложений
В то время как всю информацию, необходимую вашему приложению .NET Core, допускается хранить в исходном коде, наличие возможности изменять определенные значения во время выполнения жизненно важно в большинстве приложений. Обычно это делается посредством конфигурационного файла, который поставляется вместе с приложением.
На заметку! В предшествующих версиях .NET Framework конфигурация приложений базировалась на файле XML по имени арр.config (или web.config для приложений ASP.NET). Хотя конфигурационные XML-файлы по-прежнему можно применять, как будет показано в текущем разделе, главный способ конфигурирования приложений .NET Core предусматривает использование файлов JSON (JavaScript Object Notation — запись объектов JavaScript). Конфигурация будет подробно обсуждаться в главах, посвященных WPF и ASP.NET Core.
Чтобы ознакомиться с процессом, создайте новый проект консольного приложения .NET Core по имени FunWithConfiguration и добавьте к нему ссылку на пакет Microsoft.Extensions.Configuration.Json:
dotnet new console -lang c# -n FunWithConfiguration
-o .FunWithConfiguration -f net5.0
dotnet add FunWithConfiguration
package Microsoft.Extensions.Configuration.Json
Команды добавят к вашему проекту ссылку на подсистему конфигурации .NET Core, основанную на файлах JSON (вместе с необходимыми зависимостями). Чтобы задействовать ее, добавьте в проект новый файл JSON по имени appsettings.json. Модифицируйте файл проекта, обеспечив копирование этого файла в выходной каталог при каждой компиляции проекта:
<ItemGroup>
<None Update="appsettings.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>
Приведите содержимое файла appsettings.json к следующему виду:
{
"CarName": "Suzy"
}
На заметку! Если вы не знакомы с форматом JSON, то знайте, что он представляет собой формат с парами "имя-значение" и объектами, заключенными в фигурные скобки. Целый файл может быть прочитан как один объект, а подобъекты тоже помечаются с помощью фигурных скобок. Позже в книге вы будете иметь дело с более сложными файлами JSON.
Финальный шаг связан с
