Язык программирования C#9 и платформа .NET5 - Троелсен Эндрю
<b> </IncludeNativeLibrariesForSelfExtract></b> </PropertyGroup></Project>После запуска приведенной выше команды
dotnet publishОпределение местонахождения сборок исполняющей средой .NET Core
Все сборки, построенные до сих пор, были связаны напрямую (кроме только что законченного примера с пакетом NuGet). Вы добавляли либо ссылку на проект, либо прямую ссылку между проектами. В таких случаях (и в примере с NuGet) зависимая сборка копировалась напрямую в целевой каталог клиентского приложения. Определение местонахождения зависимой сборки не является проблемой, т.к. она размещается на диске рядом с приложением, которое в ней нуждается.
Но что насчет инфраструктуры .NET Core? Как ищутся ее сборки? В предшествующих версиях .NET файлы инфраструктуры устанавливались в глобальный кеш сборок (GAC), так что всем приложениям . NET было известно, где их найти.
Однако GAC мешает реализовать возможности параллельного выполнения разных версий приложений в .NET Core, поэтому здесь нет одиночного хранилища для файлов исполняющей среды и инфраструктуры. Взамен все файлы, составляющие инфраструктуру, устанавливаются в каталог
C:Program Filesdotnet.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_ASSEMBLIESC:Program FilesdotnetsharedMicrosoft.NETCore.Арр5.0.0В список добавляется каждый файл, на который напрямую ссылается ваше приложение, а также любые файлы исполняющей среды, требующиеся вашему приложению. Список библиотек исполняющей среды заполняется одним или большим числом файлов
*.deps.jsonMicrosoft.NETCore.Арр.deps.jsonПо мере возрастания сложности вашего приложения будет расти и список файлов в
TRUSTED_PLATFORM_ASSEMBLIESMicrosoft.EntityFrameworkCore*.csprojdotnet add package Microsoft.EntityFrameworkCoreПосле добавления пакета снова запустите приложение и обратите внимание, насколько больше стало файлов в списке. Хотя вы добавили только одну новую ссылку, пакет
Microsoft.EntityFrameworkCoreTRUSTED_PLATFORM_ASSEMBLIESРезюме
В главе была исследована роль библиотек классов .NET Core (файлов
*.dllВы ознакомились с деталями разнесения типов по пространствам имен .NET Core и отличием между .NET Core и .NET Standard, приступили к конфигурированию приложений и углубились в состав библиотек классов. Затем вы научились публиковать консольные приложения .NET Core. В заключение вы узнали, каким образом пакетировать свои приложения с применением NuGet.
Глава 17
Рефлексия типов, позднее связывание и программирование на основе атрибутов
Как было показано в главе 16, сборки являются базовой единицей развертывания в мире .NET Core. Используя интегрированный браузер объектов Visual Studio (и многих других IDE-сред), можно просматривать типы внутри набора сборок, на которые ссылается проект. Кроме того, внешние инструменты, такие как утилита
ildasm.exeSystem.Reflection
