An often overlooked aspect of the "vision" of PowerShell is that it is intended to be the back-end of a GUI console! An good example is the Citrix management c

An often overlooked aspect of the "vision" of PowerShell is that it is intended to be the back-end of a GUI console! An good example is the Citrix management console. It is a very thin Windows GUI wrapper around a bunch of PowerShell modules. Literally everything it does, and everything it shows comes from PowerShell, not from direct API calls. When managing a Citrix farm remotely, it uses WinRM PowerShell remoting, not traditional COM+ RPC. This is easy because: 1. The PowerShell runtime can be trivially embedded into any .NET app. It's just a reference and about 3 lines of biolerplate. 2. It runs "in-process", making it much faster than calling out to external shells. 3. The commands are (relatively) strongly typed, so there's no concerns about escaping, shell injection, or other similar security issues. 4. Outputs come back as lists of strongly typed C# objects, making them trivial to bind to grid views or other GUI user controls. 5. Even tree views are easy to wire up, because PowerShell has a concept of virtual "drive" providers that can wrap anything in a file/folder structure. You just write a generic "folder and item navigator" GUI control once and then you can use it with any number of providers for free. The end-result looks like a traditional GUI, but basically guarantees that anything you can do in the GUI, you can also do in the shell. It's also ridiculously easy to add a "generate a script for this change" button, because it's just spitting out the internal representation!