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

зависимая сборка копировалась напрямую в целевой каталог клиентского приложения. Определение местонахождения зависимой сборки не является проблемой, т.к. она размещается на диске рядом с приложением, которое в ней нуждается.

Но что насчет инфраструктуры .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.

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

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

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

Вспомните, что утилита ildasm.exe позволяет просматривать метаданные типов в сборке. Чтобы взглянуть на метаданные сборки CarLibrary, перейдите к разделу METAINFO в сгенерированном файле CarLibrary.il (из главы 16). Ниже приведен небольшой их фрагмент:

// ==== M E T A I N F O ===

// ===========================================================

// ScopeName : CarLibrary.dll

// MVID      : {598BC2B8-19E9-46EF-B8DA-672A9E99B603}

// ===========================================================

// Global functions

// -------------------------------------------------------

//

// Global fields

// -------------------------------------------------------

//

// Global MemberRefs

// -------------------------------------------------------

//

// TypeDef #1

// -------------------------------------------------------

//   TypDefName: CarLibrary.Car

//   Flags     : [Public] [AutoLayout] [Class] [Abstract] [AnsiClass] [BeforeFieldInit]

//   Extends   : [TypeRef] System.Object

//   Field #1

//   -------------------------------------------------------

//     Field Name: value__

//     Flags     : [Private]

//     CallCnvntn: [FIELD]

//     Field type:  String

//

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