How to build an application on top of PowerShell?

Question

Microsoft seems to be heavily pushing that their server applications (i.e SQL Server 2008, Exchange Server, etc) all have some type of PowerShell integration. The logic makes sense in that one can choose to manage the application from a GUI or CLI.

Therefore if one were to follow that trend and want to build an application that had a PowerShell interface, how would one even start?

Has anyone in the community done this type of thing? If so, what seems to be the best approach?

Update:

The UI needs to have a certain look/feel. Therefore, PowerGUI does not lend itself in this situation. However, I've used PowerGUI and do agree that it can help bridge gaps.

Part of the confusion is really whether or not hosting PowerShell is necessary in order to build an application on top of it. From what I've found, it is not (i.e. Cmdlet's). However, I have not seen anyone really discuss this in the answers yet.

Answer 1

Start here: Writing a Windows PowerShell Host Application

Answer 2

Exchange 2007 admin console hosts PS directly, and surfaces every UI action by showing a ubiquitous "and here's the PowerShell you just asked me to do" UI model). SQL Server 2005 & 8 admin consoles demo the concept of surfacing everything in a UI as scripts as a way of dogfooding scripting abilities (but there is little PowerShell support in SQL Server) (Distinction between Exchange and SQL Server's type of support added in response Shaw's comment, thanks)

PowerScripting podcast has a few interviews on topics like this. Also get-scripting podcast

Answer 3

I attended a PowerShell / MMC 3.0 Devlab at Microsoft a few years ago that taught how to do this very thing. The basic idea was to create the "management functionality" via a series of PowerShell cmdlets in a PSSnapin for your application. CLI oriented folks can just load the snapin and party on your cmdlets directly. For the GUI oriented, you build a MMC snapin that hosts a PowerShell runspace which, in response to GUI actions, executes the appropriate PowerShell cmdlets to tweak the application that is being managed. For bonus points, you display what PowerShell code will be executed by the MMC GUI such that the code can be copied and pasted into a script. There are plenty of examples out on the web that show how to host a PowerShell runspace in your (or the MMC) process and execute PowerShell script in that runspace and get back results.

Answer 4

This is an intriguing idea!

I haven't ever thought about it, and I have no idea if I think it's a good idea, but some creative things could be done.

For example, suppose you have some typical administrative-ish piece of software. Don't really care what, specifically. In a classic app dev't scenario, I'd typically try to generate a list of Command objects (things that'd implement some sort of ICommand), and then my UI would bind to those.

Suppose, now, that you were to instead create a cmdlet for each Command. The UI would more-or-less exist as a friendly interface for the core logic in the suite of cmdlets.

Yeah, ok, nothing new here. People've been doing this for a long time, building up GUIs around command-line tools. I think the key difference is that you'd instead be building up individual command line tools from the concept of the application itself. Heck, it might make more sense for both the application and the cmdlets to reference some shared library of commands instead of making the GUI sit on top of the cmdlets themselves.

Errr- sorry for the scatterbrained response. This answer was pretty much purely stream-of-consciousness. :)