Всем добра!

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

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