{AppContext.GetData ("PLATFORM_RESOURCE_ROOTS")}");

Console.WriteLine();

Console.WriteLine($"NATIVE_DLL_SEARCH_DIRECTORIES:

 {AppContext.GetData ("NATIVE_DLL_SEARCH_DIRECTORIES")}");

Console.WriteLine();

Console.WriteLine($"APP_PATHS: {AppContext.GetData("APP_PATHS")}");

Console.WriteLine();

Console.WriteLine($"APP_NI_PATHS: {AppContext.GetData("APP_NI_PATHS")}");

Console.WriteLine();

Console.ReadLine();

Запустив приложение, вы увидите большинство значений, поступающих из переменной TRUSTED_PLATFORM_ASSEMBLIES. В дополнение к сборке, созданной для этого проекта в целевом каталоге, будет выведен список библиотек базовых классов из каталога текущей исполняющей среды, C:\Program Files\dotnet\shared\Microsoft.NETCore.Арр\5.0.0 (номер версии у вас может быть другим).

В список добавляется каждый файл, на который напрямую ссылается ваше приложение, а также любые файлы исполняющей среды, требующиеся вашему приложению. Список библиотек исполняющей среды заполняется одним или большим числом файлов *.deps.json, которые загружаются вместе с исполняющей средой .NET Core. Они находятся в каталоге установки для комплекта SDK (применяется при построении программ) и исполняющей среды (используется при выполнении программ). В рассматриваемом простом примере задействован только один файл такого рода — Microsoft.NETCore.Арр.deps.json.

По мере возрастания сложности вашего приложения будет расти и список файлов в TRUSTED_PLATFORM_ASSEMBLIES. Скажем, если вы добавите ссылку на пакет Microsoft.EntityFrameworkCore, то список требующихся сборок расширится. Чтобы удостовериться в этом, введите показанную ниже команду в консоли диспетчера пакетов (в каталоге, где располагается файл *.csproj):

dotnet add package Microsoft.EntityFrameworkCore

После добавления пакета снова запустите приложение и обратите внимание, насколько больше стало файлов в списке. Хотя вы добавили только одну новую ссылку, пакет Microsoft.EntityFrameworkCore имеет собственные зависимости, которые добавляются в TRUSTED_PLATFORM_ASSEMBLIES.

Резюме

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

Вы ознакомились с деталями разнесения типов по пространствам имен .NET Core и отличием между .NET Core и .NET Standard, приступили к конфигурированию приложений и углубились в состав библиотек классов. Затем вы научились публиковать консольные приложения .NET Core. В заключение вы узнали, каким образом пакетировать свои приложения с применением NuGet.

Глава 17

Рефлексия типов, позднее связывание и программирование на основе атрибутов

Как было показано в главе 16, сборки являются базовой единицей развертывания в мире .NET Core. Используя интегрированный браузер объектов Visual Studio (и многих других IDE-сред), можно просматривать типы внутри набора сборок, на которые ссылается проект. Кроме того, внешние инструменты, такие как утилита ildasm.exe, позволяют заглядывать внутрь лежащего в основе кода CIL, метаданных типов и манифеста сборки для заданного двоичного файла .NET Core. В дополнение к подобному исследованию сборок .NET Core на этапе проектирования ту же самую информацию можно получить программно с применением пространства имен System.Reflection. Таким образом, первой задачей настоящей главы является определение роли рефлексии и потребности в метаданных .NET Core.

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

Потребность в метаданных типов