Язык программирования C#9 и платформа .NET5
<b> </IncludeNativeLibrariesForSelfExtract></b></PropertyGroup></Project>После запуска приведенной выше команды
на выходе окажется одиночный файл. Тем не менее, это только механизм транспортировки. При запуске приложения файлы собственных библиотек будут извлечены во временное местоположение на целевой машине.dotnet publishОпределение местонахождения сборок исполняющей средой .NET Core
Все сборки, построенные до сих пор, были связаны напрямую (кроме только что законченного примера с пакетом NuGet). Вы добавляли либо ссылку на проект, либо прямую ссылку между проектами. В таких случаях (и в примере с NuGet) зависимая сборка копировалась напрямую в целевой каталог клиентского приложения. Определение местонахождения зависимой сборки не является проблемой, т.к. она размещается на диске рядом с приложением, которое в ней нуждается.
Но что насчет инфраструктуры .NET Core? Как ищутся ее сборки? В предшествующих версиях .NET файлы инфраструктуры устанавливались в глобальный кеш сборок (GAC), так что всем приложениям . NET было известно, где их найти.
Однако GAC мешает реализовать возможности параллельного выполнения разных версий приложений в .NET Core, поэтому здесь нет одиночного хранилища для файлов исполняющей среды и инфраструктуры. Взамен все файлы, составляющие инфраструктуру, устанавливаются в каталог
(в среде Windows) с разделением по версиям. В зависимости от версии приложения (как указано в файлеC:\Program Files\dotnet) необходимые файлы исполняющей среды и инфраструктуры загружаются из каталога заданной версии..csprojВ частности, при запуске какой-то версии исполняющей среды предоставляется набор путей зондирования, которые будут применяться для нахождения зависимостей приложения. Существуют пять свойств зондирования, перечисленные в табл. 16.1 (все они необязательны).
Чтобы выяснить стандартные пути зондирования, создайте новый проект консольного приложения .NET Core по имени
. Приведите операторы верхнего уровня к следующему виду:FunWithProbingPathsusing System;using System.Linq;Console.WriteLine("*** Fun with Probing Paths ***");Console.WriteLine($"TRUSTED_PLATFORM_ASSEMBLIES: ");//Use ':' on non-Windows platformsvar 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 Files\dotnet\shared\Microsoft.NETCore.Арр\5.0.0В список добавляется каждый файл, на который напрямую ссылается ваше приложение, а также любые файлы исполняющей среды, требующиеся вашему приложению. Список библиотек исполняющей среды заполняется одним или большим числом файлов
, которые загружаются вместе с исполняющей средой .NET Core. Они находятся в каталоге установки для комплекта SDK (применяется при построении программ) и исполняющей среды (используется при выполнении программ). В рассматриваемом простом примере задействован только один файл такого рода —*.deps.json.Microsoft.NETCore.Арр.deps.jsonПо мере возрастания сложности вашего приложения будет расти и список файлов в
. Скажем, если вы добавите ссылку на пакетTRUSTED_PLATFORM_ASSEMBLIES, то список требующихся сборок расширится. Чтобы удостовериться в этом, введите показанную ниже команду в консоли диспетчера пакетов (в каталоге, где располагается файлMicrosoft.EntityFrameworkCore):*.csprojdotnet add package Microsoft.EntityFrameworkCoreПосле добавления пакета снова запустите приложение и обратите внимание, насколько больше стало файлов в списке. Хотя вы добавили только одну новую ссылку, пакет
имеет собственные зависимости, которые добавляются вMicrosoft.EntityFrameworkCore.TRUSTED_PLATFORM_ASSEMBLIESРезюме
В главе была исследована роль библиотек классов .NET Core (файлов
). Вы видели, что библиотеки классов представляют собой двоичные файлы .NET Core, содержащие логику, которая предназначена для многократного использования в разнообразных проектах.*.dllВы ознакомились с деталями разнесения типов по пространствам имен .NET Core и отличием между .NET Core и .NET Standard, приступили к конфигурированию приложений и углубились в состав библиотек классов. Затем вы научились публиковать консольные приложения .NET Core. В заключение вы узнали, каким образом пакетировать свои приложения с применением NuGet.
Глава 17
Рефлексия типов, позднее связывание и программирование на основе атрибутов
Как было показано в главе 16, сборки являются базовой единицей развертывания в мире .NET Core. Используя интегрированный браузер объектов Visual Studio (и многих других IDE-сред), можно просматривать типы внутри набора сборок, на которые ссылается проект. Кроме того, внешние инструменты, такие как утилита
, позволяют заглядывать внутрь лежащего в основе кода CIL, метаданных типов и манифеста сборки для заданного двоичного файла .NET Core. В дополнение к подобному исследованию сборок .NET Core на этапе проектирования ту же самую информацию можно получить программно с применением пространства именildasm.exe. Таким образом, первой задачей настоящей главы является определение роли рефлексии и потребности в метаданных .NET Core.System.Reflection
