Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

Projects►Solution (Проекты►Решение), как показано на рис. 14.3.

Добавьте в новую библиотеку классов класс Car с таким кодом:

namespace ClassLibrary1

{

  public class Car

  {

    public string PetName { get; set; }

    public string Make { get; set; }

  public int Speed { get; set; }

  }

}

Теперь, имея новую сборку, добавьте необходимые операторы 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 обеспечивает надлежащую обработку объектов с особыми потребностями во время выполнения.

Глава 15

Многопоточное, параллельное и асинхронное программирование

Вряд ли кому-то понравится работать с приложением, которое притормаживает во время выполнения. Аналогично никто не будет в восторге от того, что запуск какой-то задачи внутри приложения (возможно, по щелчку на элементе в панели инструментов) снижает отзывчивость других частей приложения. До выхода платформы .NET (и .NET Core) построение приложений, способных выполнять сразу несколько задач, обычно требовало написания сложного кода на языке C++, в котором использовались API-интерфейсы многопоточности Windows. К счастью, платформы .NET и .NET Core предлагают ряд способов построения программного обеспечения, которое может совершать нетривиальные операции по уникальным путям выполнения, с намного меньшими сложностями.

Глава начинается с определения общей природы "многопоточного приложения". Затем будет представлено первоначальное пространство имен для многопоточности, поставляемое со времен версии .NET 1.0 и называемое System.Threading. Вы ознакомитесь с многочисленными типами (Thread, ThreadStart и т.д.), которые позволяют явно создавать дополнительные потоки выполнения и синхронизировать разделяемые ресурсы, обеспечивая совместное использование данных несколькими потоками в неизменчивой манере.

В оставшихся разделах главы будут рассматриваться три более новых технологии, которые разработчики приложений .NET Core могут применять для построения многопоточного программного обеспечения: библиотека параллельных задач (Task Parallel Library — TPL), технология PLINQ (Parallel LINQ — параллельный LINQ) и появившиеся относительно недавно (в версии C# 6) ключевые слова, связанные с асинхронной обработкой (async и await). Вы увидите, что указанные средства помогают значительно упростить процесс создания отзывчивых многопоточных программных приложений.

Отношения между процессом, доменом приложения, контекстом и потоком