Я разрабатываю толстый инструмент диагностики пользовательского интерфейса, если он имеет прямую интеграцию с PowerShell

Question

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

Стоит ли встраивать выполнение PowerShell в пользовательский интерфейс инструмента? Что делают другие команды разработчиков?

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

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

Answer 1

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

Одной из причин встраивания PowerShell является выполнение тех же командлетов PowerShell, которые входят в состав ядра диагностики и мониторинга ядра. Таким образом, вам не нужно дублировать функциональность между механизмом приложения диагностического инструмента и командлетами, которые ваши клиенты используют для автоматизации. Похоже, код, который вы используете для диагностики и мониторинга в приложении, отличается от кода в командлетах? Или между приложением и командлетами существует общий код?

Еще одна причина для встраивания PowerShell - позволить самому приложению создавать сценарии, но это не соответствует вашему сценарию.

Еще одна причина для встраивания PowerShell - это если вы внедряете новый хост - т.е. вы предоставляете уникальную функциональность редактирования или оболочки. Некоторые приложения, которые делают это, PowerGUI (который позволяет запускать сценарии IIRC) и PowerShell Plus.

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

Answer 2

Я согласен и с Джайкулом, и с Китом Хиллом - ответ - да.

Есть несколько подходов, которые вы можете использовать. Но в целом я бы порекомендовал вам: а) создавать ключевые командлеты как часть пользовательского интерфейса для вашего приложения и б) создавать графический интерфейс поверх PowerShell (так же, как это делала команда Exchange.

Делая это, следуйте указаниям Microsoft (все приложения должны иметь интерфейс PowerShell), который также используется другими (например, VMware, и даже Symantec использует PowerShell в своих приложениях.

Создание командлетов (и, возможно, поставщика) довольно просто - недавно был выпущен отличный дизайнер командлетов (см. http://blogs.msdn.com/powershell/archive/2009/10/16/announcing-open-source-powershell-cmdlet-and-help-designer.aspx) для этого инструмента.

Надеюсь, это поможет!

Answer 3

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