Всем добра!

Появилась необходимость дать пользователям возможность писать скрипты в приложении, то есть нужно сделать API который будет высовывать наружу некоторые методы и структуры и скриптовый язык, который сможет использовать этот API, и умеет работать с файловой системой итп.
Идеальный вариант поддержка двух языков: С# чтобы разработка в рамках API не сильно отличалась от работы разработчика приложения. и код мог перетекать без особых изменений из приложения в скрипты и обратно.
И какой-нибудь простенький скриптовый язык, который учится за день и может только вызывать предоставленные ему методы API
Существуют ли готовые годные решения, и вообще в каком направлении копать?

А Roslyn это что такое? студия 2010 посмотреть не получается.

МСУ,
Я сейчас рассматриваю все варианты. Просто задача внезапно сегодня обрисовалась и пока даже еще не знаю с какой стороны удачнее зайти.
XSLT у меня уже собирает кастомный XAML, теперь нужно кастомизировать поведение. грубо говоря нужно чтобы пользователь мог дописывать в приложение свои обработчики событий ни в чем себе не отказывая.

МСУ,
Спасибо за идею. покапаю в этом направлении, и возможно вопрос с полноценным языком возможно решен. осталось решить проблему с простым языком скриптов для непрограммистов.

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

Пробовал Roslyn полноценная поддержка скриптов на C# реализуется в 20 строчек кода. тынц
Нет дебагера из коробки, хотя есть доступ ко всем кишкам компилятора чтобы это сделать. и нужны .Net 4.5, VS 2012, SDK, собственно Roslyn. Ну и пока неясное будущее CTP.

Простой язык скриптов XSLT
Хорошая шутка
собственно скрипты в XSLT это уже расширение. и на практике оказалось выходит внезапными тормозами и подвисаниями, ну и МС XSLT 1.0 только поддерживают, который только для простого трансформа пригоден.

IronPython попробовал. как-то он неинформативно сообщает об ошибках. простую опечатку, если не знать где, можно искать достаточно долго, хотя может что-то делаю не так.

МСУpempсобственно скрипты в XSLT это уже расширение. и на практике оказалось выходит внезапными тормозами и подвисаниями
Всё зависит от конкретной реализации задачи.

Может быть, тогда как ускорить компиляцию скриптов в рантайме? штатными средствами что-то более-менее крупное при первом вызове занимало 0.5-1.5 секунды на клиентском компьютере, с учетом того, что это происходит не на старте приложения, а во время работы пользователя это оказалось не приемлемо.
МСУpempну и МС XSLT 1.0 только поддерживают, который только для простого трансформа пригоден.
Первой версии хватает за глаза. Что есть "простой" трансформ для меня загадка. Он пригоден для любого трансформа.

Значит просто не приходилось сталкиваться. У меня половина проекта на XSLT, отлично решает поставленные задачи, но раньше периодически наступали на грабли, связанные с тем что XSLT 1.0 чего-то не умеет, а XSLT 2.0 не поддерживается. потом написали свой претрансформер, который приводит сырые данные в более удобную для XSLT форму и теперь на паримся.

МСУПродолжай дальше заниматься садомазахизмом. А нормальные вменяемые люди будут юзать плагины на MEF и MAF. Там и студийный дебаг и всё остальное.
Все это отлично. вот только нанимать и обучать нормальных вменяемых людей по всему миру, открыть еще один отдел сапорта который будет учить людей пользоваться студией. итп. выйдет на порядок дороже, чем написать свой скриптовый движок для простой логики, в которой большинство клиентов будут просто свои цифры и буквы подставлять. Когда-то даже простой переход с .net 3.5 на 4 неожиданно создал кучу геморроя при обновлении и развертывании у новых клиентов. хотя казалось бы у всех есть сисадмины, интернет, автообновление... но мир внезапно оказался неидеальным, а на большом количестве это становится фактором с которым приходится считаться и закладывать в бюджет.

К слову Roslyn весьма интересная штука, как оказалось. Простой редактор текста с проверкой синтаксиса пишется в пару десятков строк. смущает пока еще неясное будущее.

МСУpempМожет быть, тогда как ускорить компиляцию скриптов в рантайме?
Никак. Только оптимизировать алгоритм. Разговор о сферическом коне в вакууме.

А как влияет оптимизация алгоритма на скорость компиляции? скорее наоборот менее эффективный но более прямолинейный алгоритм скомпилируется быстрее. К слову, затык произошел на просто однопроходном парсинге строки 10-300 символов, в котором сложно что-то соптимизировать.

МСУ Сомневаюсь на счет дороже. На разработку своего движка уйдут годы, его так же нужно поддерживать, развивать, ловить баги и прочее. Не всё так прозрачно, как тебе кажется. Проще взять готовые движки, чем изобратеть велосипеды.
Собственно потому я сейчас и рассматриваю все предложенные и не предложенные варианты. хотя на рослине, между делом, рабочий движок сделал, полностью удовлетворяющий требованиям, за исключением отладчика. Но что-то подсказывает, что есть подводные камни.

МСУОптимизация кода, ровно как и его рефакторинг, нередко приводят к уменьшению итогового объема. Как следствие, скорость компиляции может варьироваться от большего значения к меньшему.
хорошая фраза для учебника, но на практике имеем метод с одним пробегом по строке и парой строчек с вызовом StringBuilder который первый раз вместе с JIT выполняется 3мс, последующие 0мс и при первом вызове из XSLT 700мс Если тут может помочь оптимизация, то после нее код должен выполнятся за отрицательное время.

МСУЕжики кололись, пугались, но продолжали есть кактус...
Может и кактус, но полноценный скриптовый движок с проверкой синтаксиса и зачатком отладчика набросал за пару кофебрейков, можно сказать получил уже приемлемый результат, еще даже не приступая к решению задачи. На мой взгляд глупо не исследовать такие возможности только по причине того, что уже есть какой-то любимый инструмент.

tAZARПочему бы при написании и тестировании скрипта не компилировать его каждый раз, а во время выполнения приложения загружать уже сохраненную скомпилированную версию?

Этот вариант тоже прорабатывается, с ним просто все понятно и нет технических вопросов. Здесь вопросы сугубо развертывания и удовлетворения целевой аудитории. Задачи для скриптов разноплановые, какие-то ближе к плагинам, какие-то ближе к конфигам, есть задачи которые сделал один раз и забыл, есть требующие постоянной обработки напильником. Еще есть две категории конечных пользователей: программисты. и не программисты, но технические специалисты. С первыми все просто, им нужна только точка входа и документация. здесь тот же MEF 100% покрывает задачу, но их меньшинство. Для большинства же идеальный вариант иметь скрипт в тексте. чтобы можно было нажать кнопку в приложении, посмотреть результат, поправить скрипт, ctr+s и снова нажать кнопку в приложении итд. если билдить сборки такая доводка выйдет в разы дольше. + учить людей пользоваться студией, кому-то все это ставить прописывать пути итп мелочи, но в масштабах как уже говорил такие мелочи набегают на серьезные затраты, тут нужно несколько раз взвесить все варианты прежде чем делать выбор в пользу конкретной реализации.

К слову о "инопланетной поделке", на текущий момент планируется что эта поделка будет основным компилятором C# 6.0. а большинство из готовых сторонних скриптовых движков с которыми я ознакомился - заброшенные проекты.