Much less has been written about using PowerShell interactively from within a WPF application – a powerful approach that opens up a wealth of possibilities in your development process.  This series of blog posts will introduce some key concepts required to develop such an application.

Part 1: Host Applications and PowerShell API

If you have run a PowerShell script or written a script in the PowerShell ISE (Integrated Scripting Environment), you have already encountered host applications.  According to MSDN, a host application “is any application that loads the Windows PowerShell engine into its process and uses it to perform operations. This could be a graphical user interface (GUI) that runs Windows PowerShell commands to perform an administrative task, or it could be a console application that provides an interactive session for the user.”

As you might now suspect, two host applications are provided with your PowerShell installation: the default console-based PowerShell.exe and the graphical PowerShell Integrated Scripting Environment (ISE).  Whereas PowerShell.exe is your traditional shell environment (for those familiar with bash or the Command Prompt), the ISE allows you edit, run and debug scripts in a more IDE-like environment (e.g., Visual Studio, Eclipse).  The ISE included with PowerShell version 3.0, in particular, adds such familiar features as Intellisense to make script authoring easier than ever. 

Figure 1. PowerShell.exe	Figure 2. PowerShell Integrated Scripting Environment (ISE)

Beginning with PowerShell 2.0, you and I are now able to write our own custom host interface, using APIs that let you integrate the PS engine into your own applications.

Implementing a custom host is not for everyone; after all, there are already two mature and fully-featured programs for the vast majority of your scripting needs.  But in cases where you wish to extend your application to run PowerShell cmdlets without launching a separate process, or where you wish to add interactive PowerShell power (no pun intended) to your application without needing the overhead of the ISE, this can be a very attractive option.

The Basics

Despite our eventual goal of a WPF graphical interface, I will start our journey with the oft-presented console application.  In order to use the PowerShell runtime in your project, you must have access to the System.Management.Automation namespace.  If you are using Visual Studio, make sure to add a reference to the DLL in your project. 

NOTE: For Windows 7 and Windows 8 users, this DLL is located in X:\Windows\assembly\GAC_MSIL\System.Management.Automation , where X is the drive on which Windows is installed.

using System.Management.Automation;

One of the simplest applications using the PowerShell engine does the following:

• Initialize the PowerShell pipeline in the default host
• Execute a predetermined command
• Display its output to the console

As you might have noticed, I added another new term in my above description: pipeline. The terminology can be overwhelming, so let me summarize briefly before continuing: a pipeline holds commands or script to be run by the PowerShell engine via a host application.

    class Program
    {
        static void Main(string[] args)
        {
            var pipeline = PowerShell.Create();
 
            pipeline.AddCommand("Get-Command");
 
            foreach (PSObject result in pipeline.Invoke())
            {
                Console.WriteLine("{0,-15}{1,-20}",
                    result.Members["CommandType"].Value,
                    result.Members["Name"].Value
                );
            }
        }
    }

Using the PowerShell.Create() method in the simple application creates a new pipeline that eventually holds our command.  When we invoke (i.e., execute) the pipeline's contents with Invoke(), the console application waits for the pipeline to complete before returning an iterable list of PSObject objects.  These are powerful objects which allow you to access results much as you would in the traditional PowerShell.exe application:

This program may be extremely limited in function, but by successfully running it, you are officially on the path toward our eventual WPF PowerShell snazzy graphical host!

In Part 2 of this series, we will take two further key steps needed to take our application graphical: learn how to invoke a pipeline asynchronously, a must for any modern GUI application, and learn about runspaces. 

As an associate consultant working for Microsoft Consulting Services, I have the privilege of working with a wide range of technologies and products on a daily basis. That makes it exceptionally difficult to describe what this blog is and what it may be in the future – consider it an evolving concept, one that I have the time and wherewithal to maintain.

Being grateful for the helpful advice I seek and find every day, it only feels right that I try to share some of the tips, tricks and stories that I feel others may find useful. Rarely, if ever, will I consider my ideas to be the “right way” to accomplish a task, but my hope is that they may illuminate your own path.

The opinions expressed here are my own and do not represent Microsoft, and any content posted here comes "AS IS" – no guarantees, no warranties. That said, please enjoy this little corner of the Internet and feel free to leave your comments and feedback!

Phil