Я разрабатываю толстый инструмент диагностики UI, должен он иметь прямую интеграцию к PowerShell
Существует также Valentina. Я бегунок e через этот продукт, когда я работал над некоторым Реальным Основным проектом. Версия RB очень хороша.
3 ответа
К счастью, встраивание механизма PowerShell и выполнение команд / сценариев и получение результатов обратно довольно тривиально. Тем не менее, я не уверен, что в вашем сценарии я бы встроил PowerShell. Вы спрашиваете, предпочитают ли люди запускать сценарии из своих собственных оболочек или из среды поставщиков инструментов. Я не могу говорить за всех, но оболочки и редакторы, которые я использую, поддерживают некоторые изящные функции для отладки, сворачивания кода, выделения синтаксиса, нескольких пространств выполнения и т. Д. Я не уверен, что вы захотите приложить усилия, чтобы предоставить аналогичные возможности .
Одна из причин встраивания PowerShell - выполнение тех же командлетов PowerShell как часть основного механизма диагностики и мониторинга. Таким образом, вы не Необязательно дублировать функциональность ядра приложения диагностического инструмента и командлетов, которые ваши клиенты используют для автоматизации. Похоже, код, который вы используете для диагностики и мониторинга в приложении, отличается от кода в командлетах? Или есть общий код между приложением и командлетами?
Еще одна причина для встраивания PowerShell - позволить самому приложению быть скриптовым, но это, похоже, не соответствует вашему сценарию.
Еще одна причина встраивать PowerShell - это если вы реализуете новый хост, то есть предоставляете уникальные функции редактирования или оболочки. Некоторые приложения, которые делают это, - это PowerGUI (который позволяет запускать сценарии IIRC) и PowerShell Plus.
Еще одна причина, по которой я встроил PowerShell в приложение, заключается в том, что я знал, что могу получить определенные результаты с гораздо меньшим количеством кода, чем эквивалентный C # код.
Да, основная причина, по которой я бы подумал о фактическом внедрении PowerShell в этот сценарий, заключается в том, что ваш пользовательский интерфейс может генерировать сценарии PowerShell для действий, которые пользователи выполняют в пользовательском интерфейсе, поэтому они могли видеть, что происходит, и легко узнавать, как это автоматизировать. Это потребовало бы разработки пользовательского интерфейса на основе PowerShell с самого начала ... поэтому мне кажется, что вам лучше просто предоставить командлеты и образцы;)
Я согласен и с Джайкулом, и с Китом Хиллом - ответ - да.
Есть несколько подходов, которые вы можете использовать. Но в целом я бы порекомендовал вам: а) создавать ключевые командлеты как часть пользовательского интерфейса вашего приложения и б) создавать графический интерфейс поверх 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 ) для этого инструмента.
Надеюсь, это поможет!