<b> </IncludeNativeLibrariesForSelfExtract></b>
</PropertyGroup>
</Project>
После запуска приведенной выше команды
dotnet publish
на выходе окажется одиночный файл. Тем не менее, это только механизм транспортировки. При запуске приложения файлы собственных библиотек будут извлечены во временное местоположение на целевой машине.
Определение местонахождения сборок исполняющей средой .NET Core
Все сборки, построенные до сих пор, были связаны напрямую (кроме только что законченного примера с пакетом NuGet). Вы добавляли либо ссылку на проект, либо прямую ссылку между проектами. В таких случаях (и в примере с NuGet) зависимая сборка копировалась напрямую в целевой каталог клиентского приложения. Определение местонахождения зависимой сборки не является проблемой, т.к. она размещается на диске рядом с приложением, которое в ней нуждается.
Но что насчет инфраструктуры .NET Core? Как ищутся ее сборки? В предшествующих версиях .NET файлы инфраструктуры устанавливались в глобальный кеш сборок (GAC), так что всем приложениям . NET было известно, где их найти.
Однако GAC мешает реализовать возможности параллельного выполнения разных версий приложений в .NET Core, поэтому здесь нет одиночного хранилища для файлов исполняющей среды и инфраструктуры. Взамен все файлы, составляющие инфраструктуру, устанавливаются в каталог
C:Program Filesdotnet
(в среде Windows) с разделением по версиям. В зависимости от версии приложения (как указано в файле
.csproj
) необходимые файлы исполняющей среды и инфраструктуры загружаются из каталога заданной версии.
В частности, при запуске какой-то версии исполняющей среды предоставляется набор путей зондирования, которые будут применяться для нахождения зависимостей приложения. Существуют пять свойств зондирования, перечисленные в табл. 16.1 (все они необязательны).
Чтобы выяснить стандартные пути зондирования, создайте новый проект консольного приложения .NET Core по имени
FunWithProbingPaths
. Приведите операторы верхнего уровня к следующему виду:
using System;
using System.Linq;
Console.WriteLine("*** Fun with Probing Paths ***");
Console.WriteLine($"TRUSTED_PLATFORM_ASSEMBLIES: ");
//Use ':' on non-Windows platforms
var list = AppContext.GetData("TRUSTED_PLATFORM_ASSEMBLIES")
.ToString().Split(';');
foreach (var dir in list)
{
Console.WriteLine(dir);
}
Console.WriteLine();
Console.WriteLine($"PLATFORM_RESOURCE_ROOTS:
{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 FilesdotnetsharedMicrosoft.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.
