Язык программирования C#9 и платформа .NET5

Теперь, имея новую сборку, добавьте необходимые операторы using:

 using System.IO;
 using System.Runtime.Loader;

Метод, добавляемый следующим, требует наличия операторов using для пространств имен System.IO и System.Runtime.Loader, которые вы уже добавили в Program.cs. Вот код этого метода:

 static void LoadAdditionalAssembliesDifferentContexts
 {
  var path =
  Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
  "ClassLibrary1.dll");
  AssemblyLoadContext lc1 =
  new AssemblyLoadContext("NewContext1",false);
  var cl1 = lc1.LoadFromAssemblyPath(path);
  var c1 = cl1.CreateInstance("ClassLibrary1.Car");
  AssemblyLoadContext lc2 =
  new AssemblyLoadContext("NewContext2",false);
  var cl2 = lc2.LoadFromAssemblyPath(path);
  var c2 = cl2.CreateInstance("ClassLibrary1.Car");
  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");
  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 обеспечивает надлежащую обработку объектов с особыми потребностями во время выполнения.