Ссылки на NuGet и сборки

Подключение NuGet-пакетов через Properties и вручную через

Подключение внешних сборок

Движок скриптов поддерживает ссылки на внешние сборки — как из файла, так и из NuGet.

Важно: подключение сборок доступно только внутри Script.csx, который является аналогом вашего Program.cs в «обычном» C#.

Через окно Properties

Начиная с новых версий EyeAuras, зависимости можно подключать не только вручную через #r, но и через отдельное окно Script Properties.

Сначала откройте свой скрипт и нажмите кнопку Properties.

Кнопка Properties

После этого откроется окно Script Properties, где во вкладке NuGet можно:

  • искать пакеты
  • выбирать версию
  • устанавливать пакет
  • обновлять уже установленный пакет
  • удалять ненужные пакеты

Вкладка NuGet

Это самый удобный способ для большинства сценариев: не нужно помнить точный синтаксис, вручную редактировать директивы или идти на сайт NuGet, если вы просто хотите быстро подключить библиотеку.

Рядом находится и вкладка References. Она нужна для немного другого сценария: там можно добавить либо уже загруженную сборку из самой EyeAuras, либо внешнюю DLL по пути. Это особенно полезно, если нужной библиотеки просто нет на NuGet.

Как это связано с #r

Под капотом это все тот же механизм ссылок на пакеты. Окно Properties просто дает удобный интерфейс поверх #r "nuget: ...".

То есть:

  • если вам удобно пользоваться интерфейсом, можно вообще не трогать директивы руками
  • если вы предпочитаете полный контроль, все еще можно писать #r вручную

Оба варианта задают ссылку на пакет. Восстановление зависимостей — отдельный шаг: ошибки версии, сервера пакетов или загрузки смотрите в диагностике скрипта. Произвольные native assets и MSBuild targets пакета не становятся автоматически поддержанными.

По имени пакета — из NuGet

Укажите точный ID и версию пакета. Например, в Script.csx можно подключить Newtonsoft.Json и разобрать строку JSON:

csharp
#r "nuget: Newtonsoft.Json, 13.0.3"

using Newtonsoft.Json.Linq;

var settings = JObject.Parse("{\"delayMs\":250}");
var delayMs = settings.Value<int>("delayMs");
Log.Info($"Delay: {delayMs} ms");

После успешного восстановления и компиляции в Event Log появится Delay: 250 ms. Наличие директивы или строки в Installed Packages ещё не доказывает, что пакет восстановился и загрузился. Доступность этой версии на сервере и совместимость бинарных зависимостей с вашей сборкой EyeAuras требуют проверки. Подключение типов также не регистрирует службы в DI — для этого некоторым SDK нужна extension.

Если пакет уже подключен, через Properties -> NuGet его будет удобнее обновить или удалить. Ручной режим остается полезным, если вы хотите быстро вставить зависимость прямо в код или переносите уже готовый Script.csx.

По пути к сборке — из файла

Этот вариант требует существующей DLL по указанному пути. Путь ниже — пример, замените его своим. На другой машине такой файл сам не появится; для распространения вместе со скриптом используйте Embedded Resources. Ссылка на одну DLL не гарантирует загрузку всех её зависимостей.

csharp
#r "assemblyPath: D:\Work\EAExile\EAExileAgent.Shared.dll"

Log.Info("Assembly reference declared"); // Проверяйте диагностику и доступность нужных типов

По имени сборки — из памяти

Этот способ запрашивает доступные host метаданные по имени сборки. Он не скачивает отсутствующую библиотеку и не устанавливает runtime. В частности, речь о сборках, которые:

  • уже загружены EyeAuras, но не входят в список сборок, подключаемых по умолчанию
  • были загружены через Assembly.Load или любым другим способом, но уже находятся в AssemblyLoadContext/AppDomain
  • доступны механизму разрешения метаданных host; наличие библиотеки в GAC само по себе этого не гарантирует

Исторически EyeAuras подключал ОЧЕНЬ много сборок по умолчанию — более 300. Это экономит пользователям время на предварительную настройку зависимостей для каждого C#-действия, BT-ноды и т. д., но в долгосрочной перспективе такой подход не является хорошим решением.

Постепенно всё больше сборок будет исключаться из списка подключаемых по умолчанию, а вместо этого появятся более удобные механизмы автодополнения, которые позволят легко подключать именно те библиотеки, которые нужны вашему скрипту. В будущем это упростит обновление программы для всех.

csharp
#r "assemblyName: Grpc.Net.Client"

Log.Info("Assembly reference declared"); // Это ещё не проверка сетевого вызова

Что выбрать на практике

Обычно логика такая:

  • если библиотека есть на NuGet, почти всегда лучше подключать ее именно как NuGet-пакет
  • если библиотеки на NuGet нет, можно сослаться на локальную DLL через assemblyPath, в том числе через вкладку Properties -> References
  • если файл нужно распространять вместе со скриптом, посмотрите еще на Embedded Resources

Для большинства пользователей оптимальный путь теперь такой:

  1. Открыть скрипт.
  2. Нажать Properties.
  3. Перейти во вкладку NuGet.
  4. Найти пакет, выбрать версию и нажать Add Package или Update Package.

Это проще, безопаснее и нагляднее, чем сразу начинать с ручного редактирования Script.csx.

Если же нужного пакета в NuGet нет, откройте соседнюю вкладку References и добавьте внешнюю сборку по пути.