Powershell 2.0 is considered to be part of the "Windows Manangement Framework" and has a download page. Powershell 2.0, WinRM(remoting service), and BITS 4(Background Intelligent Transfer Service) makeup this management framework. Powershell 2.0 was shipped with Windows 7 and Server 2008 R2, and was made available for Windows XP SP3 and Vista SP1. Version 2 is completely compatible with version 1 - so any scripts written with version 1 will work in version 2.
On Dec 22, 2009 a new Powershell 2.0 SDK was put out for dowload by Microsoft.
There are two videos from the Micrsoft PDC2009 - SVR12 and SVR13 that show writing a simple GUI using the powershell API. During these videos it is mentioned that the powershell ISE (Integrated Scripting Environment) was developed with this same API.
There are Microsoft examples on how to host powershell within an application- which is what a developer would do to utilize powershell within their own application. This is the direction that Microsoft has started with their enterprise level tools. Now developers can embed powershell so that you can develop functionality as a cmdlet/script and the exercise that functionality from the GUI (Silverlight,Web,Windforms, or WPF).
The first hurdle in hosting powershell is getting a reference to it. System.Management.Automation does not show up in the .Net list of items. Browse to
C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\
and there you find the System.Management.Automation.dll. Verify that your reference works. If you can enter the code line below in the project and Intellisense works (the create method is visible) - you have the right version of the DLL in place.
PowerShell ps = PowerShell.Create();
(Note the example line of code is from a Microsoft
example.)
The Microsoft links on how to host powershell have a good number of starting projects to show the usage of some parts of the API. The examples there are only Console examples. The Code posted on the Powershell blog for the SVR12/13 did use GUI's, however I did not appreciate these exampels as much - as it added a few users onto my machine for showing the security aspects that they used in the demo. The examples are a start, however it will take more for work to get a command of using the full power of the Powershell 2.0 SDK.
Powershell SDK can also execute powershell commands on remote machines using the WinRM functionality - if the remote machine allows the execution and the credentials of the user attempting are authorized. This remote execution allows for collecting information from remote machines back to one location for reporting/processing.
The Microsoft PDC 2009 presentations were targeting development using powershell API toward the Admin community, and controlling what access a given a user - programatically controlling this based on security roles.
With functionality being stored completely in PowerShell cmdlets/scripts, the practice forces a complete seperation of Logic and Presentation - which simplifies testing. Reworking the presentation layer is also greatly simplified. The PDC2009 videos described how the Exchange 2007 team wrote their first GUI in 10 months,as they developed their powershell cmdlets- when they were asked to reskin their GUI; it took only two weeks - the Exchange team was euphoric with that result. They did not have to put everything in the GUI, as the more advanced, or special case scenarios, could be handled by a powershell cmdlet only - thereby reducing clutter in the GUI and overall simplified maintenance.