Console.WriteLine("*** Loading Additional Assemblies in Different Contexts ***");
Console.WriteLine($"Assembly1 Equals(Assembly2) {cl1.Equals(cl2)}");
Console.WriteLine($"Assembly1 == Assembly2 {cl1 == cl2}");
Console.WriteLine($"Class1.Equals(Class2) {c1.Equals(c2)}");
Console.WriteLine($"Class1 == Class2 {c1 == c2}");
}
В первой строке кода с применением статического метода Path.Combine() строится каталог для сборки ClassLibrary1.
На заметку! Вас может интересовать, по какой причине создавалась ссылка на сборку, которая будет загружаться динамически. Это нужно для того, чтобы при компиляции проекта сборка ClassLibrary1 тоже компилировалась и помещалась в тот же каталог, что и DefaultAppDomainApp. В данном примере поступать так попросту удобно. Ссылаться на сборку, которая будет загружаться динамически, нет никакой необходимости.
Далее в коде создается объект AssemblyLoadContext, имеющий имя NewContext1 (первый параметр конструктора) и не поддерживающий выгрузку (второй параметр), который будет использоваться для загрузки сборки ClassLibrary1 и последующего создания экземпляра класса Car. Если какие-то фрагменты кода выглядят для вас незнакомыми, то они будут подробно объясняться в главе 19. Процесс повторяется для еще одного объекта AssemblyLoadContext, после чего сборки и классы сравниваются на предмет эквивалентности. В результате выполнения метода LoadAdditionalAssembliesDifferentContexts() вы получите следующий вывод:
*** Loading Additional Assemblies in Different Contexts ***
Assembly1 Equals(Assembly2) False
Assembly1 == Assembly2 False
Class1.Equals(Class2) False
Class1 == Class2 False
Вывод демонстрирует, что та же самая сборка была дважды загружена в домен приложения. Как и следовало ожидать, классы тоже отличаются.
Добавьте новый метод, который будет загружать сборку из того же самого объекта AssemblyLoadContext:
static void LoadAdditionalAssembliesSameContext()
{
var path =
Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
"ClassLibrary1.dll");
AssemblyLoadContext lc1 =
new AssemblyLoadContext(null,false);
var cl1 = lc1.LoadFromAssemblyPath(path);
var c1 = cl1.CreateInstance("ClassLibrary1.Car");
var cl2 = lc1.LoadFromAssemblyPath(path);
var c2 = cl2.CreateInstance("ClassLibrary1.Car");
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
Console.WriteLine("*** Loading Additional Assemblies in Same Context ***");
Console.WriteLine($"Assembly1.Equals(Assembly2) {cl1.Equals(cl2)}");
Console.WriteLine($"Assembly1 == Assembly2 {cl1 == cl2}");
Console.WriteLine($"Class1.Equals(Class2) {c1.Equals(c2)}");
Console.WriteLine($"Class1 == Class2 {c1 == c2}");
}
Главное отличие приведенного выше кода в том, что создается только один объект AssemblyLoadContext. В таком случае, если сборка ClassLibrary1 загружается дважды, то второй экземпляр сборки является просто указателем на ее первый экземпляр. Выполнение кода дает следующий вывод:
*** Loading Additional Assemblies in Same Context ***
Assembly1.Equals(Assembly2) True
Assembly1 == Assembly2 True
Class1.Equals(Class2) False
Class1 == Class2 False
Итоговые сведения о процессах, доменах приложений и контекстах загрузки
К настоящему времени вы должны иметь намного лучшее представление о том, как сборка .NET Core обслуживается исполняющей средой. Если изложенный материал показался слишком низкоуровневым, то не переживайте. По большей части .NET Core самостоятельно занимается всеми деталями процессов, доменов приложений и контекстов загрузки. Однако эта информация формирует хороший фундамент для понимания многопоточного программирования на платформе .NET Core.
Резюме
Задачей главы было исследование особенностей обслуживания приложения .NET Core платформой .NET Core. Как вы видели, давно существующее понятие процесса Windows было внутренне изменено и адаптировано под потребности среды CoreCLR. Одиночный процесс (которым можно программно манипулировать посредством типа System.Diagnostics.Process) теперь состоит из домена приложения, которое представляет изолированные и независимые границы внутри процесса.
Домен приложения способен размещать и выполнять любое количество связанных сборок. Кроме того, один домен приложения может содержать любое количество контекстов загрузки для дальнейшей изоляции сборок. Благодаря такому дополнительному уровню изоляции типов среда CoreCLR обеспечивает надлежащую обработку объектов с особыми потребностями во время выполнения.
Глава 15
Многопоточное, параллельное и асинхронное программирование
Вряд ли кому-то понравится работать с приложением, которое притормаживает во время выполнения. Аналогично никто не будет в восторге от того, что запуск какой-то задачи внутри приложения (возможно, по щелчку на элементе в панели инструментов) снижает отзывчивость других частей приложения. До выхода платформы .NET (и .NET Core) построение приложений, способных выполнять сразу несколько задач, обычно требовало написания сложного кода на языке C++, в котором использовались API-интерфейсы многопоточности Windows. К счастью, платформы .NET и .NET Core предлагают ряд способов построения программного обеспечения, которое может совершать нетривиальные операции по уникальным путям выполнения, с намного меньшими сложностями.
