На заметку! Каталог, в котором выполняется приложение, зависит от того, как вы его запускаете. Если вы применяете команду dotnet run, то текущим каталогом будет тот, где располагается файл проекта. Если же вы используете Visual Studio, тогда текущим будет каталог, в котором находится скомпилированная сборка, т.е. .\bin\debug\net5.0. Вам необходимо должным образом скорректировать путь к документу Word.
На платформах .NET и .NET Core исполняемые файлы не размещаются прямо внутри процесса Windows, как в случае традиционных неуправляемых приложений. Взамен исполняемый файл .NET и .NET Core попадает в отдельный логический раздел внутри процесса, который называется
• Домены приложений являются ключевым аспектом нейтральной к операционным системам природы платформы .NET Core, поскольку такое логическое разделение абстрагирует отличия в том, как лежащая в основе операционная система представляет загруженный исполняемый файл.
• Домены приложений оказываются гораздо менее затратными в смысле вычислительных ресурсов и памяти по сравнению с полноценными процессами. Таким образом, среда CoreCLR способна загружать и выгружать домены приложений намного быстрее, чем формальный процесс, и может значительно улучшить масштабируемость серверных приложений.
Отдельный домен приложения полностью изолирован от других доменов приложений внутри процесса. Учитывая такой факт, имейте в виду, что приложение, выполняющееся в одном домене приложения, не может получать данные любого рода (глобальные переменные или статические поля) из другого домена приложения, если только не применяется какой-нибудь протокол распределенного программирования.
На заметку! Поддержка доменов приложений в .NET Core изменилась. В среде .NET Core существует в точности один домен приложения. Создавать новые домены приложений больше нельзя, поскольку это требует поддержки со стороны исполняющей среды и в общем случае сопряжено с высокими накладными расходами. Изоляцию сборок в .NET Core обеспечивает класс ApplicationLoadContext (рассматриваемый далее в главе).
С выходом версии .NET Core класс AppDomain считается почти полностью устаревшим. Хотя большая часть оставшейся поддержки предназначена для упрощения перехода из .NET 4.x в .NET Core, она по-прежнему может приносить пользу, как объясняется в последующих двух разделах.
С помощью статического свойства AppDomain.CurrentDomain можно получать доступ к стандартному домену приложения. При наличии такой точки доступа появляется возможность использования методов и свойств AppDomain для проведения диагностики во время выполнения.
Чтобы научиться взаимодействовать со стандартным доменом приложения, начните с создания нового проекта консольного приложения по имени DefaultAppDomainApp. Модифицируйте файл Program.cs, поместив в него следующий код, который просто выводит подробные сведения о стандартном домене приложения с применением нескольких членов класса AppDomain:
using System;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Runtime.Loader;
Console.WriteLine("***** Fun with the default AppDomain *****\n");
DisplayDADStats();
Console.ReadLine();
static void DisplayDADStats()
{
// Получить доступ к домену приложения для текущего потока.
AppDomain defaultAD = AppDomain.CurrentDomain;
// Вывести разнообразные статистические данные об этом домене.
Console.WriteLine("Name of this domain: {0}",defaultAD.FriendlyName);
// Дружественное имя этого домена
Console.WriteLine("ID of domain in this process: {0}",defaultAD.Id);
// Идентификатор этого процесса
Console.WriteLine("Is this the default domain?: {0}",
defaultAD.IsDefaultAppDomain());
// Является ли этот домен стандартным
Console.WriteLine("Base directory of this domain: {0}",
defaultAD.BaseDirectory);
