На заметку!
При создании автономного развертывания обязателен идентификатор исполняющей среды, чтобы процессу опубликования было известно, какие файлы .NET Core Runtime добавлять к вашему прикладному коду.Команда помещает ваше приложение и его поддерживающие файлы (всего 235 файлов) в каталог selfcontained
Опубликование автономных приложений в виде единственного файла
В большинстве ситуаций развертывание 235 файлов (для приложения, которое выводит всего лишь несколько строк текста) вряд ли следует считать наиболее эффективным способом предоставления вашего приложения пользователям. К счастью, в .NET 5 значительно улучшена возможность опубликования вашего приложения и межплатформенных файлов исполняющей среды в виде единственного файла. Не включаются только файлы собственных библиотек, которые должны существовать вне одиночного файла ЕХЕ.
Показанная ниже команда создает однофайловое автономное развертывание для 64-разрядных ОС Windows и помещает результат в каталог по имени singlefile
dotnet publish -r win-x64 -c release -o singlefile --self-contained
true -p:PublishSingleFile=true
Исследуя файлы, которые были созданы, вы обнаружите один исполняемый файл (CSharpCarClient.exe
CSharpCarClient.pdb) и четыре DLL-библиотеки, специфичные для ОС. В то время как предыдущий процесс опубликования производил 235 файлов, однофайловая версия CSharpCarClient.exe имеет размер 54 Мбайт! Создание однофайлового развертывания упаковывает 235 файлов в единственный файл. За снижение количества файлов приходится платить увеличением размера файла.Напоследок важно отметить, что собственные библиотеки тоже можно поместить в единственный файл. Модифицируйте файл CSharpCarClient.csproj
После запуска приведенной выше команды dotnet publish
Определение местонахождения сборок исполняющей средой .NET Core
Все сборки, построенные до сих пор, были связаны напрямую (кроме только что законченного примера с пакетом NuGet). Вы добавляли либо ссылку на проект, либо прямую ссылку между проектами. В таких случаях (и в примере с NuGet) зависимая сборка копировалась напрямую в целевой каталог клиентского приложения. Определение местонахождения зависимой сборки не является проблемой, т.к. она размещается на диске рядом с приложением, которое в ней нуждается.
Но что насчет инфраструктуры .NET Core? Как ищутся ее сборки? В предшествующих версиях .NET файлы инфраструктуры устанавливались в глобальный кеш сборок (GAC), так что всем приложениям . NET было известно, где их найти.
Однако GAC мешает реализовать возможности параллельного выполнения разных версий приложений в .NET Core, поэтому здесь нет одиночного хранилища для файлов исполняющей среды и инфраструктуры. Взамен все файлы, составляющие инфраструктуру, устанавливаются в каталог C:\Program Files\dotnet
.csproj) необходимые файлы исполняющей среды и инфраструктуры загружаются из каталога заданной версии.В частности, при запуске какой-то версии исполняющей среды предоставляется набор
Чтобы выяснить стандартные пути зондирования, создайте новый проект консольного приложения .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: