How To Create A Gui In Powershell

Using PowerShell to Write PowerShell GUIs? You May Be Making a Mistake

by Crista Perlton, on Apr 22, 2021 1:18:00 PM

I think we can all agree that Spiderman Peter Parker's Uncle Ben was right: "With great PowerShell comes great responsibility." Okay, obviously I added the "shell" part. But it's true. PowerShell is really, really powerful, and that can be too much responsibility for some people to want to go near.

A PowerShell graphical user interface (GUI) can help lower-XP PowerShell users to interact more safely and confidently with PowerShell.

PowerShellGUI

GUIs are great, because they:

let users run PowerShell by themselves
provide a job-specific interface to enforce limited input
limit who can do what with PowerShell in that given situation
give "immediate visual feedback" (aka lets you know when you've forgotten a required form, for example)
are meant to be intuitive and easy-to-use for anyone
make inaccessible technology accessible (especially for Linux)

The best kind of GUI is one that's built by a UX engineer using a desktop framework (e.g., WPF or Win Forms) and an IDE (e.g., Visual Studio).

When I was just starting to use PowerShell, a GUI like this would have prevented me from, say, importing an internal certificate to ALL our servers instead of just the test servers... But that's a story for a different day.

But these are waaay too expensive to the business, and by the time you're doing that, you'll have built an application (which isn't the point of PowerShell). I think you already know this (especially if you've read some of my other articles). So, what are your options for a very basic, middle ground, "good enough" GUI for PowerShell?

Writing a PowerShell GUI USING PowerShell is not a good idea, in my opinion and experience. Let me show you how to do this anyway while explaining why it's a land you don't want to enter (trust me… I learned the hard way), and then I'll explain a much more promising option.

Two (Not Great) Options for Building PowerShell GUIs with PowerShell

Use WPF and XAML in PowerShell

You may be tempted to use WPF and PowerShell. This is possible, of course, because PowerShell is based on .NET.

The problem with this method is that just because PowerShell can use .NET doesn't mean it will work well with other .NET technologies. The UX of a PowerShell desktop framework GUI will be rough because it won't be built with an IDE. It will also be complex, difficult-to-read, and a write-once script. And maybe more importantly, it will be so large that maintaining it will be a real slog.

If it's a .NET-based GUI you're looking for, using C# makes way more sense… which brings us back to "you're actually building an application and don't need PowerShell in this case.

But let's say you still want to give WPF and XAML at try. The steps involved in this process include:

hand-crafting a XAML file to create a GUI
combining your script and the PowerShell GUI by adding code to
- import and read the XAML code of the form.
- dynamically create variables assigned to each named control
- display the form

To learn more, I recommend checking out the Adam the Automator blog. There is also a tool called PoshGUI that acts as a kind of "IDE," but don't confuse its capabilities with the IDE you'd get from Visual Studio.

Text-based Menu

Let me start by heading off a likely question: Is a text-based menu even "graphical"?

There are good arguments to say yes and others that say no. But since it's a possibility and people do use it, let's consider this as a type of PowerShell GUI.

The general steps to building one of these:

Using the Write-Host cmdlet to display choices to the console
Use a combination of the Read-Host cmdlet and the ChoiceDescription Class to read text input and define the prompts someone can select from

Creating a text-based menu with PowerShell is significantly less complicated than using WPF, but it's also not easy. Want to learn more? Adam the Automator for the win again.

Remember, the menu created with this method is very rudimentary (which is one reason why people say a text-based menu isn't truly "Graphical"). There is a tool to create a "Terminal User Interface (TUI)" for PowerShell that make your text-based menus more visually appealing. It's not to my taste, though. If I'm using a text-based menu, it's usually because it doesn't matter if it doesn't look very nice.

If I need a good PowerShell GUI, I far prefer running scripts with auto-generated UIs.

New call-to-action

Running Scripts with Auto-generated UIs

Instead of trying to make an application out of a script, I prefer to use Otter to run scripts with auto-generated UIs.

How to Do It

Otter can automatically generate a UI around your scripts. It does this in two ways:

Comment-based Help
Otter's Job Template Feature

Otter lets you add comments and descriptions, which as I've stated before, is the key to near-perfect PowerShell scripts (definitely read this article if you need to learn how to do Comment-Based Help).

And by using job templates, you enable self-service. The next time anyone needs to run a job, even if they don't have permission to run scripts, can then use the template, which will restrict inputs AND will remind you when you've forgotten to fill out required fields. (In an untemplated world, you'd have to bug your manager any time you needed to do this and wait around til they were free.)

Why I Think It's the Better Choice

It really boils down to two very simple-but-mighty reasons:

GUIs are automatic – no extra time spent making a GUI by hand
PowerShell scripts previously impossible for someone in, say, Accounting to run are now runnable because they're in a simple GUI made-to-order by Otter

At the end of the day, you do less work and have a more useful UI.

Don't Be Overpowered by PowerShell

PowerShell rules. It's powerful as heck and can do lots of good things. But it is NOT the best choice for everything. Just like when you're testing your scripts, not everything has to be a script or automated!

I've told you why trying to write a PowerShell GUI in PowerShell is a bad idea—but since you can make up your own mind, I also showed you how to do two common methods. I'd suggest giving Otter a try to see how automated UIs work for you.

Democratizing PowerShell with GUIs is just one way you can help your team "level up":