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

Question

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

Существует VSTA (.NET эквивалент VBA для COM), но, насколько я понимаю, я бы платить лицензионный сбор за каждую установку моего приложения. Это открытый исходный код приложение, так что это не будет работать.

Существует также, например, встраивание интерпретаторов (IronPython?), но я не понимаю, как это позволило бы подвергать «объектную модель» (см. ниже) внешним (или внутренним) сценариям.

подвопросы:

• Что такое история интерфейса сценариев в .NET? Это как-то тривиально сделать в .NET?
• например. Можно ли объявить некоторые объекты .NET в моем приложении и содержащиеся в них объекты доступными извне во время выполнения?
• Как внешние скрипты могут получить доступ к моему приложению (через объектную модель)?

---

Справочная информация:

Однажды я разработал и реализовал довольно сложный интерфейс сценариев для приложения Macintosh для сбора и анализа данных с масс-спектрометра (Mac OS, System 7 ) и позже COM-интерфейс для приложения Windows.

Оба были разработаны с "объектной моделью" и классами (которые могут иметь свойства). Это перегруженные слова, но в интерфейсе сценариев объектная модель контекста по сути представляет собой иерархию содержания объектов определенных классов. Классы имеют свойства, списки содержащихся объектов и являются не только данными, но также могут иметь глаголы (действия / методы). Например. в случае Macintosh определенный объект приложения может содержать объект сбора данных, который имеет свойства для напряжений, используемых в приборе, и глагол fireLater - все это видно из внешнего сценария.

Обратите внимание, что в обоих случаях классы / объекты в языке программирования, используемом для реализации приложения, не имели ничего общего с объектной моделью сценариев. В случае с Macintosh механизмы, используемые для реализации интерфейса сценариев, были определены Apple. Были также некоторые стандарты, определенные Apple, о том, как проектировать объектную модель. Например, стандартизированные имена для некоторых общих свойств в классах.

Или как в интерфейсах COM, представленных в приложениях Microsoft Office, где объект приложения можно использовать для добавления в свой список документов (с побочным эффектом создания представления документа в графическом интерфейсе).

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

На Macintosh реализация интерфейса сценариев была очень сложной. Поддержка этого в Metroworks 'Библиотека классов C ++ (имя меня сейчас ускользает) сделала ее намного проще.

Answer 1

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

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

Answer 2

[РЕДАКТИРОВАТЬ: как подробно описано в комментариях к этому, предполагая, что у вас есть значительная потребность включить внутренние сценарии, где вы размещаете фрагменты или функции, которые кто-то дает вам для настройки вашего приложения, в отличие от чисто внешнего сценария, где один предоставляет фасад, позволяющий людям копать вещи из вашего приложения на более жесткой предопределенной основе]

IronRuby и IronPython очень аккуратны и подходят для этого (но, как говорится в другом ответе, PowerShell может подойти, если у вас есть инфраструктурный тип).

РЕДАКТИРОВАТЬ: Другие идеи для включения внутренних сценариев

• с использованием Windows Workflow Foundation (раскрытие действий для него и / или размещение экземпляров рабочих процессов)
• с использованием языка выражений Spring.NET (что кратко, легко документировать и изучать, но удивительно мощно)

РЕДАКТИРОВАТЬ 2 июня 2011: IronJS также может быть подходящим кандидатом, есть Hanselminutes, который говорит это через .

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

public interface ICustomModule
{
    void ProcessBatch(IBatch batch)
}

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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