Здравствуйте, Sаныч, Вы писали:
S>С обычными ясно через MetadataReference.CreateFromFile. С нугетами по сложнее — их же нужно сначата отрезолвить, скачать и только потом компилировать.
S>Какой то есть уже готовый класс для таких вещей?
Ну судя вот по этому в Roslyn Scripting API какие-то зачатки резолвинга NuGet присутствуют.
Но в документации какого-то упоминания я не нашел.
А можете чуть подробнее описать, что вы хотите получить?
Потому что у меня фраза "C# как скрипт", ассоциируется с "голым" C# кодом, в котором просто нет механизмов чтобы сослаться даже на внешнюю сборку, что уж там говорить про NuGet.
Поэтому у вас это или задается где-то вовне (и вы определяете список того, что доступно скрипту, а там уж используйте любой механизм ссылки на сборки) или у вас некий аналог файла проекта, но тогда, мне кажется, проще делать полноценную компиляцию.
Здравствуйте, Sаныч, Вы писали:
S>С обычными ясно через MetadataReference.CreateFromFile. С нугетами по сложнее — их же нужно сначата отрезолвить, скачать и только потом компилировать.
S>Какой то есть уже готовый класс для таких вещей?
Здравствуйте, Михаил Романов, Вы писали:
МР>Потому что у меня фраза "C# как скрипт", ассоциируется с "голым" C# кодом, в котором просто нет механизмов чтобы сослаться даже на внешнюю сборку, что уж там говорить про NuGet.
Имелся ввиду подход с использованием CSharpCompilation. В этом случае добавление ссылок происходит через передачу путей к файлам. Конечно же, ссылки сохраняются не в коде напрямую, а в отдельном файле.
Примерно, но нет. Мне схожее нужно в своей программе, где код на шарпе прописывается. А тут отдельная среда. Если уж отдельная среда, тогда лучше студия.
Здравствуйте, Sаныч, Вы писали:
S>Имелся ввиду подход с использованием CSharpCompilation. В этом случае добавление ссылок происходит через передачу путей к файлам. Конечно же, ссылки сохраняются не в коде напрямую, а в отдельном файле.
Понял.
Увы, ничего готового посоветовать не могу.
Судя по вот такому комментарию разработчики Roslyn считают что резолвинг зависимостей из NuGet — это не задача компилятора, а задача системы сборки.
Я попробовал поискать что-то готовое, но увы...
Может быть вам рассмотреть вариант с генерацией MsBuild проекта на лету и получения результатов через него? Это потребует, как минимум, наличия SDK на конечной машине (на сколько помню в Runtime пакет MSBuild не входит), но может дополнительные условия не такие уж и страшные?
Например, есть вот такой проект MSBuildProjectCreator, который на первый взгляд выглядит вполне живым и достаточно простым в использовании.
Здравствуйте, Sаныч, Вы писали:
S>С обычными ясно через MetadataReference.CreateFromFile. С нугетами по сложнее — их же нужно сначата отрезолвить, скачать и только потом компилировать.
S>Какой то есть уже готовый класс для таких вещей?
Здравствуйте, Михаил Романов, Вы писали:
МР>разработчики Roslyn считают что резолвинг зависимостей из NuGet — это не задача компилятора, а задача системы сборки.
Да я и не настаиваю на том, что это задача компилятора. Поэтому вопрос был скорее есть ли готовая вещь, которая умеет "подготавливать данные" для компиляции. Но видимо нет.
МР>Т.е. не задействуется локальный кэш, не резолвится весь граф зависимостей, ...
Вот-вот, поэтому и вопрос встал. Там ведь еще поиск совместимостей, если зависимости не полностью совместимы.
МР>Это потребует, как минимум, наличия SDK на конечной машине
А вот этого как раз и нет. Программа для пользователей. Как внутренний скрипт. Даже рантайм не всегда установлен, сделано авто скачивание. А в перспективе совсем перейти на AOT. Поэтому MsBuild не подходит никак.
S>А вот этого как раз и нет. Программа для пользователей. Как внутренний скрипт. Даже рантайм не всегда установлен, сделано авто скачивание. А в перспективе совсем перейти на AOT. Поэтому MsBuild не подходит никак.
А на сколько в такой схеме допустимо работать с произвольными NuGet-пакетами? Не будет ли тут потенциальных проблем?
Просто, например, если ограничить список библиотек, которые доступны пользователю, то задача может резко упроститься.
Например, можно поставлять в дистрибутиве все разрешенные библиотеки и более ничего.
S>Какой то есть уже готовый класс для таких вещей?
Готового не встречал.
Но знаю, что есть пакет NuGet.Core (этот уже deprecated, но есть поновее), с помощью которого можно реализовать скачивание пакета с учётом всех зависимостей.
Идея такая: "исталируем" пакет со всеми зависимостями в известное место.
А в сгенерированную сборку добавляем обработчик для события assembly resolve домена. В обработчике ищем в папке инсталляции пакета требуемую сборку и возвращаем ее.
Вот тут можно посмотреть пример такой "установки" из нугета.
Это тоже сервер приложений, который умеет устанавливать и запускать приложения из нугет-пакетов. Типа такой docker на минималках
Проект тоже очень старый (еще под .net 4.x), ном может найдете что-то полезное для себя по части работы с нугет.
Если нам не помогут, то мы тоже никого не пощадим.
