Building a PowerShell GUI (Part 1)

If you would like to read the other parts in this article series please go to:

• Building a PowerShell GUI (Part 2)
• Building a PowerShell GUI (Part 3)
• Building a PowerShell GUI (Part 4)
• Building a PowerShell GUI (Part 5)
• Building a PowerShell GUI (Part 6)
• Building a PowerShell GUI (Part 7)
• Building a PowerShell GUI (Part 8)
• Building a PowerShell GUI (Part 9)
• Building a PowerShell GUI (Part 10)
• Building a PowerShell GUI (Part 11)
• Building a PowerShell GUI (Part 12)
• Building a PowerShell GUI (Part 13)

Those of you who read my articles on a regular basis know that I tend to write a lot of content about Windows PowerShell. There are a couple of reasons for this. First of all, Microsoft is said on more than one occasion that PowerShell is eventually going to become the preferred mechanism for managing Windows servers. That being the case, I try to help get everyone ready for the transition by writing about ways to perform various administrative tasks in PowerShell. My other reason is a bit more personal. I was a programmer long before I started writing about networking, and working with PowerShell gives me a chance to go back to my roots.

Regardless of my reasoning for writing about PowerShell, there is one thing that I come across time and time again. There are a significant number of people who simply do not like working in a command line environment. Some really don’t like writing code. Others have no problem with writing code, but they don’t feel completely comfortable with giving their users a PowerShell based solution to a business problem because PowerShell is a command line environment as opposed to the point and click environment to which users have become so accustomed.

Believe it or not, PowerShell does not limit you to the text based interface that has become almost synonymous with a PowerShell environment. Microsoft makes it possible to create a GUI interface for your PowerShell scripts. That way, if you have a script that you need to give to an end user (or if you just prefer to look at a graphical interface yourself), you can break away from the standard blue text interface.

OK, so what does it take to build a PowerShell GUI? When I first discovered that it was possible to build a PowerShell GUI, my mind instantly flashed back to my old Radio Shack Color Computer that I used to write programs on in the 1980s. That computer, like so many others of the time, booted to a text based BASIC programming environment. This environment was based around the command line, but if you wanted to switch to graphical mode you could do so by entering three commands (PMODE, PCLS, and SCREEN). I have to admit that I assumed that PowerShell would be somewhat similar. I expected PowerShell to offer a command called Set-GraphicMode or something similar that could be used to switch to GUI mode. Alas, such a command doesn’t exist.

Although the process of creating a GUI for your PowerShell scripts is not super difficult, it may require you to move a bit outside of your comfort zone because you are going to have to use some external tools. Specifically, you are going to need to use Visual Studio. You are also going to need the Microsoft .NET Framework version 4.x and you will of course need PowerShell.

So what does the process of building a PowerShell GUI look like? Well, as previously explained, you won’t be able to accomplish your goal by using only native PowerShell. In reality, there are going to be three different files that will be used.

The first of these files is your PowerShell script. If you have already got a PowerShell script that you want to turn into a graphical “application”, you can definitely do so. Your PowerShell script will typically require very little modification.

The second file that you are going to need is an XAML file. The XAML file is the piece that defines what the graphical user interface will look like. XAML files are coded using a scheme that looks a lot like XML. The good news is that you don’t have to manually code an XAML manually. Visual Studio provides a tool that will let you drag and drop various elements onto a canvas to create your graphical interface. As you do, Visual Studio will write the necessary XAML code for you.

The third component that you are going to need is a secondary PowerShell script. If you stop and think about it, you have got a PowerShell script that acts as a text based version of the application that you are building. You also have an XAML file that builds the graphical user interface. This third file ties the other two together.

As it stands right now, your original PowerShell script and your XAML file are two completely separate entities that are not aware of one another. If you were to execute your PowerShell script right now, the output would be text based because the script is unaware of the existence of the XAML file. Similarly, the interface defined by the XAML file is little more than a picture at this point. The interface doesn’t do anything by itself.

The secondary PowerShell script that you are going to have to create is sometimes referred to as a dialog script (I have heard it referred to by a variety of different names). In any case, this script’s job is to tie your original PowerShell script to the graphical environment that you have created.

Out of the entire process, building the dialog script requires the most work. There are two main reasons for this. First of all, the dialog script leverages the .NET Framework. Sure, the script contains some standard PowerShell cmdlets, but some administrators may find that the script looks completely foreign because of the .NET code that exists within the script.

The other reason why building the dialog script requires some work is because it doesn’t just make your PowerShell script and the XAML file aware of one another (although that is part of its job). It also handles functionality mapping. Let me give you an example.

Suppose for a moment that when you created the XAML file, you defined an OK button as a part of your script’s graphical interface. PowerShell has no idea of what you want to happen when someone clicks OK. You have to create something called an event handler that defines a button click as an event and tells PowerShell what should happen when someone clicks the button.

Let me give you another example. Let’s suppose that you have created a PowerShell script that asks a user to make some sort of choice. You can use the XAML file to define a drop down list, but unless you connect that drop down list to something, the list will be empty and it won’t do anything. You can use the dialog script to tie the drop down list into your original PowerShell script thereby populating the list. Likewise, the dialog script also tells PowerShell what to do when the user does choose an option from the list.

Conclusion

As you can see, there is much more to creating a PowerShell GUI than adding a few lines of code to an existing PowerShell script. You will need to create an XAML file that defines the GUI and a dialog script that controls the GUI’s behavior and links the GUI to your script. This requires some work, but I plan to step you through the process in a way that will hopefully make the process as painless as possible.