Язык сценариев для встраивания в приложения C # /. NET?

[только аналогичный вопрос Я могу найти ответ уже давно и содержит ссылку в основном на IronPython. Хочу рассмотреть и другие варианты]

У нас есть приложение для комплексного анализа данных, написанное на C #. Приложение должно предоставлять пользователям сложные средства настройки их задач анализа данных. В настоящее время мы используем смесь файлов конфигурации и таблиц Excel, чтобы указать это, но это становится громоздким, поэтому мы ищем язык сценариев для встраивания.

Какой самый простой язык сценариев для встраивания C # /. NET? Можно ли как-то встроить VBA аналогично Excel / Word? Или, возможно, используется JavaScript / Lua?

Излишне говорить, что во встроенных скриптах должно быть легко предоставить доступ к некоторым API и объектам из основного приложения.


.net c# embed scripting
person Eli Bendersky    schedule 20.01.2009    source источник
comment
Вы уже пробовали SILK? Он был разработан для этой цели.   -  person Jonathan Wood    schedule 12.11.2019

Ответы (12)


arrow_upward
11
arrow_downward

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

Еще один отличный вариант - IronRuby. Основное различие, которое я вижу, было бы, если бы ваши разработчики / пользователи имели какой-либо опыт работы с Python или Ruby, который можно было бы перенести.

На самом деле, в конце концов, вашим лучшим вариантом будет язык, который легче всего адаптируется пользователями. Если они не примут это и не смогут работать более продуктивно, чем при старом методе, это не стоит усилий.

person chills42    schedule 20.01.2009
comment
+1, по моему опыту, Python очень легко учить и изучать, и непрограммисты относятся к нему так же хорошо, как и тяжелые программисты. - person orip; 20.01.2009
comment
Python легко изучить; использование классов .NET Framework в IronPython менее эффективно. Но это проблема, с которой вы столкнетесь с любым языком сценариев, который взаимодействует с фреймворком, и вы, вероятно, не захотите использовать тот, который этого не делает. Я использую IronPython и очень доволен результатом. - person Robert Rossney; 20.01.2009

arrow_upward
8
arrow_downward

Может быть, Boo?

person Jon Skeet    schedule 20.01.2009
comment
Чем он лучше IronPython? - person Eli Bendersky; 20.01.2009
comment
@eliben: лучше? Что может быть лучше IronPython? Это другое. Он имеет необязательную статическую типизацию и очень подходит для указания DSL, которые могут хорошо соответствовать вашему сценарию. См. ayende.com/Blog/archive/2007/12. /17/The-Boo-Language.aspx - person orip; 20.01.2009
comment
Да, но он довольно новый, неподдерживаемый и непонятный. Нет шансов получить по нему книгу, сообщество пользователей невелико, а библиотек немного. В конце концов, мне нужно корпоративное приложение, поэтому Бу не подойдет. - person Eli Bendersky; 20.01.2009
comment
Книга: manning.com/rahien - person Mauricio Scheffer; 20.01.2009
comment
Библиотеки: это язык .NET, поэтому все, что есть в мире .NET, принадлежит вам. - person Mauricio Scheffer; 20.01.2009
comment
встраивать его очень просто: boo.codehaus .org / Boo + как + встроенный + язык + сценариев - person Mauricio Scheffer; 20.01.2009
comment
@eliben: В чем особенность Бу? Манифест Boo датируется ~ 2004 годом, что всего на год позже, чем IronPython. Если вам нужно что-то получше, чем IronPython, вы должны явно определить свои критерии. Вы сказали, что вам нужен вариант, отличный от IronPython. Я дал тебе одну. - person Jon Skeet; 20.01.2009
comment
Джон Скит - спасибо за это. Я как раз обсуждаю этот вариант. Надеюсь, это не звучит резко - я рад за ссылки - person Eli Bendersky; 20.01.2009

arrow_upward
7
arrow_downward

Lua великолепен! Lua отлично работает с .NET. Я написал сообщение в блоге о том, как начать встраивать Lua и C #, возможно, стоит проверить:

http://blog.apterainc.com/software/embedding-lua-and-c/

person mmattax    schedule 20.01.2009
comment
Фу! Я получаю 404 по вашей ссылке. - person Frank Hale; 19.06.2012
comment
Вот почему stackoverflow требует, чтобы содержимое ссылки, относящейся к ответу, было включено в этот ответ (чтобы избежать мертвых ссылок). - person myermian; 19.01.2014

arrow_upward
3
arrow_downward

Я бы посмотрел только на XAML Windows Workflow. Вы можете повторно разместить конструктор и предоставить настраиваемые действия, которые можно перетаскивать и использовать для управления данными любым удобным для них способом. ОЧЕНЬ наглядно. В настоящее время я использую это в одном из своих приложений, и пользователям это нравится. Хотя для этого требуется небольшая кривая обучения, это намного меньше, чем у обычного языка сценариев, и люди, кажется, могут понять его довольно быстро, особенно те, кто имеет опыт использования блок-схем и Visio.

person Lusid    schedule 20.01.2009
comment
Это может быть очень полезным и удобным для пользователя, если требуемая настройка достаточно хорошо определена и легко параметризуется. В противном случае вы вернетесь к предоставлению языка сценариев. - person Larry Fix; 21.01.2009
comment
Я согласен ... но именно поэтому вы создаете общие действия, чтобы обрабатывать столько различных процессов, сколько вам нужно. В таком случае действия заменяют отдельные языковые структуры ключевых слов, такие как if, while и т. Д. - person Lusid; 21.01.2009

arrow_upward
2
arrow_downward

Я знаю, что вы просили технологию создания сценариев, но основная потребность - контроль кода для непрограммистов. Мы используем правила ILOG для .Net, чтобы удовлетворить эту потребность.

person Amy B    schedule 20.01.2009

arrow_upward
2
arrow_downward

А как насчет C #? Нет причин, по которым вы не можете позволить пользователю писать C #, а затем безопасно загружать его в другой домен приложений со всеми правильными ограничениями и мерами безопасности.

person Dmitri Nesteruk    schedule 20.01.2009
comment
Нет, я думаю, C # слишком многословен и сложен для пользователей. - person Eli Bendersky; 20.01.2009

arrow_upward
2
arrow_downward

А как насчет JScript.NET или PowerShell

person Christian C. Salvadó    schedule 20.01.2009

arrow_upward
2
arrow_downward

Я считаю, что использование C # через CodeDom - очень мощное решение.

person abatishchev    schedule 20.01.2009

arrow_upward
2
arrow_downward

Были упомянуты Boo и IronPython, но не забывайте IronScheme, F # или любой из другие языки, которые были перенесены на виртуальную машину CIL и имеют возможность компиляции / интерпретации во время выполнения.

person Aaron    schedule 28.01.2009

arrow_upward
2
arrow_downward

IronRuby с каждым днем ​​выглядит лучше.

person Eric Nicholson    schedule 05.08.2009

arrow_upward
1
arrow_downward

Существует много-много-много языков сценариев. Что лучше для вас, зависит от того, что вы пытаетесь сделать.

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

person Dour High Arch    schedule 20.01.2009

arrow_upward
0
arrow_downward

Я бы также проголосовал за использование C # для написания ваших расширений. Если у вас нет веской причины, такой как существующая база пользователей, уже знакомых с python, ruby ​​или boo, использование другого языка только усложняет работу и увеличивает стоимость обучения.

person Yes - that Jake.    schedule 20.01.2009