Как я начинаю разрабатывать и реализовывать интерфейс сценария для моего приложения.NET?

Взгляните на PowerShell .

Он позволяет вам программировать простые командлеты, которые можно использовать в сценариях. Он также поддерживает иерархические контейнеры (по умолчанию у вас есть файловая система, реестр, хранилище сертификатов и т. Д.).

Чтобы получить бесплатный и простой в реализации язык сценариев .NET , обратите внимание на C #.

См. мой ответ на аналогичный вопрос.

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

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

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

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

Я использовал CS-Script , чтобы создать что-то вроде вашего. В моем случае я определил интерфейс в своем приложении. Затем скрипту просто нужно было реализовать этот интерфейс, чтобы его можно было запускать из приложения. Мое приложение предназначалось для обработки отсканированных изображений, и поэтому мой интерфейс выглядел примерно так:

public interface ICustomModule
{
    void ProcessBatch(IBatch batch)
}

Таким образом, мой сценарий мог получить доступ к объектной модели, которую я определил в своем приложении (в моем случае через IBatch). Хорошо то, что во время разработки я мог использовать для сценария обычный проект библиотеки классов: IntelliSense, отладка ... Я не помню точных деталей, но у меня в основном был переключатель в моем приложении, который велел приложению использовать ссылается на библиотеку классов вместо сценария.

Кроме того, я создал дополнительный интерфейс, который позволял настраивать сценарии: сценарий мог определять набор свойств, которые затем отображались моим приложением в сетке свойств. Думаю, я использовал эту версию здесь , поскольку в то время она казалась более гибкой. Таким образом, вы можете не только разрешить пользователям настраивать сценарий, но также можете предоставить помощь в виде описаний, вариантов выбора, значений по умолчанию ... Сетка свойств довольно расширяема: в одном случае у нас был сценарий, который отображал специальный форма для определения некоторых сложных настроек.

Изменить: В приложении, конечно же, не было ссылки на библиотеку классов «отладки». Просто нужно загрузить сборку ...

Я предлагаю вам рассмотреть Dynamic Language Runtime как стратегию для реализации интерфейса сценариев. Подробности:

• Сайт CodePlex DLR
• MSDN .NET 4 Обзор DLR

DLR в настоящее время поддерживает IronPython и IronRuby , а также можно найти ряд других языковых реализаций на CodePlex . Если вы заинтересованы в создании языка, специфичного для вашего приложения, у Bitwise Magazine есть хороший учебник , статья .

Сессия PDC09 Дино Филанда Использование динамических языков для создания приложений с поддержкой сценариев заслуживает внимания. Вы можете найти демонстрационный код здесь .

Я реализовал CS-Script в качестве платформы сценариев последней для написанной мной системы рабочих процессов. У каждого необходимого wrokflow были разные условия, которые диктовали, какие пользователи будут подписываться на различные задачи и кто будет получать электронные письма. С помощью модели сценариев стало легко вводить новые шаги в рабочие процессы и обрабатывать уникальные требования, которые требовались для этих задач.

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

С CS-Script у вас есть полный доступ к вашим объектам; то есть, когда ваш скрипт импортирует ваши сборки, вы можете создать экземпляр своего объекта в своем коде скрипта. Кроме того, вы можете сохранить свои скомпилированные скрипты и просто предоставить им параметры. Если ваши сборки используют объект параметров или словарь, вы можете передать этот сценарий и выполнить методы для объектов, содержащихся в объекте параметра.

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

Учебное пособие по встраиванию Lua в приложение C # можно найти здесь .

Редактировать: Вероятно, также стоит отметить, что Lua изначально разрабатывался как встроенный язык сценариев, и, как следствие, интерпретатор обладает широкими возможностями настройки. Хост-приложение может ограничивать практически любой аспект возможностей интерпретации как часть модели безопасности; например разрешение или запрет сценариям устанавливать сетевые подключения или запись в файлы и т. д.

Также вы спрашивали о внешних сценариях. Сделать вашу программу доступной для внепроцессных сценариев делается так же, как вы делаете ее доступной для внепроцессных приложений: путем предоставления стандартизованного интерфейса автоматизации через какой-то протокол связи. В Windows для межпроцессного взаимодействия на одном компьютере это чаще всего будет COM, но это также может быть WCF, удаленное взаимодействие TCP, RPC или любое количество других стандартов связи. То, что вы выберете, во многом зависит от того, как создано ваше приложение и какой вид внешней автоматизации вы намереваетесь делать.