.NET Разработчик: “День 2605. #ЗаметкиНаПолях 5 Малоизвестных Функций C#, Которые Упростя…”

День 2605. #ЗаметкиНаПолях
5 Малоизвестных Функций C#, Которые Упростят Вашу Жизнь
Фреймворк уже имеет надёжные инструменты для решения различных проблем, но многие из них мало известны. Сегодня рассмотрим некоторые.

1. OperatingSystem.IsX вместо RuntimeInformation
В течение многих лет проверка текущей ОС в .NET означала написание чего-то вроде:

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
  //…
}

Теперь появились более чистые варианты:
- OperatingSystem.IsWindows,
- OperatingSystem.IsLinux,
- OperatingSystem.IsMacOS
и т.п.

if (OperatingSystem.IsWindows())
{
  //…
}

2. Правильная изоляция плагинов с помощью AssemblyLoadContext
Если вы когда-либо пытались создать систему плагинов в .NET, вы знаете, насколько болезненны конфликты сборок. Загрузите две версии одной и той же зависимости, и внезапно всё перестаёт работать. AssemblyLoadContext позволяет загружать сборки изолированно, так что два плагина могут зависеть от разных версий одной и той же DLL, не мешая друг другу. Вот минимальный код для начала:

class PluginLoadContext : AssemblyLoadContext
{
  private AssemblyDependencyResolver _resolver;

  public PluginLoadContext(string path) => 
    _resolver = new(path);

  protected override Assembly? Load(AssemblyName name)
  {
    var path = _resolver
      .ResolveAssemblyToPath(name);
    
    return path != null 
     ? LoadFromAssemblyPath(path)
     : null;
  }
}

Теперь каждый плагин существует в своей среде. Вы также можете их выгружать, что очень важно для длительно работающих процессов, таких как серверы.

3. Разбор зависимостей с помощью AssemblyDependencyResolver
AssemblyDependencyResolver, получив путь к плагину или сборке, определяет, откуда должны браться зависимости:

var resolver = 
 new AssemblyDependencyResolver(pluginPath);
var path = resolver
 .ResolveAssemblyToPath(assemblyName);

Вы получаете правильные правила разрешения зависимостей, соответствующие тому, как это обычно делает .NET, но с областью действия в контексте плагина. Так вы избегаете неприятных сюрпризов, когда плагин ссылается на Newtonsoft.Json 13.0.1, а хост-приложение использует 12.0.3.

4. Получение версий сборок без ошибок
Часто в коде можно встретить что-то такое:

var version = Assembly
 .GetExecutingAssembly()
 .GetName()
 .Version;

Дело в том, что это значение не всегда совпадает с версией, которую вы указали в проекте. Это версия сборки, а не обязательно версия файла или информационная версия. Какая из них вам нужна?
- AssemblyName.Version - версия сборки, полученная во время компиляции,
- FileVersionInfo.GetVersionInfo(assembly.Location).FileVersion - версия файла,
- AssemblyInformationalVersionAttribute - семантическая версия, вроде 1.0.0-beta+sha.abc123.

Лучший подход – выражаться более явно:

var version = Assembly
  .GetExecutingAssembly()
  .GetCustomAttribute<AssemblyInformationalVersionAttribute>()?
  .InformationalVersion;

Так вы получите именно ту строку, которую хотели передать, а не то, что MSBuild по умолчанию присвоил вашей DLL.

5. Получение зависимостей из контейнера с помощью ActivatorUtilities
Иногда нужно создать объект, который не зарегистрирован в контейнере, но имеет зависимости, которые зарегистрированы. Используйте ActivatorUtilities:

var myService = ActivatorUtilities
 .CreateInstance<MyService>(serviceProvider);

Это говорит контейнеру: «Я знаю, что MyService не зарегистрирован, но, пожалуйста, внедри все необходимые ему сервисы». Это удобный обходной путь, который избавляет вас от необходимости создавать неудобные фабрики или засорять код логикой разрешения сервисов.

Источник: https://blog.stackademic.com/if-youre-not-using-these-5-net-features-you-re-working-too-hard-0aefbf5a6fdc?gi=bb3ac273e638