PowerGUI and .NET Framework 4.0

On my current project, we use PowerShell scripts to automate our UI testing.  We’ve been writing and running the scripts in the PowerGUI Script Editor, an excellent tool that’s also free.  When we upgraded our application to run on version 4.0 of the .NET Framework from 3.5, we lost the ability to run PowerShell scripts in debug mode from PowerGUI.

The only work-around for this I’ve found (at least until a version of PowerGUI built on .NET 4.0 comes out), is a registry hack that forces all the .NET apps on the machine to use the latest version of the CLR.  You can find more details in this user discussion at powergui.org, or this discussion on stackoverflow.com.

My First PowerShell Cmdlet

We’ve been using PowerShell to write automated tests of the UI on my current project.  One of the tasks I took on today was creating a custom cmdlet to enable us to select radio buttons.

I already had an existing assembly of cmdlets to work with, so I just added a new class (SelectRadioButton) to it.  Next, I added references to System.Management.Automation and System.Windows.Automation. With these references in place, I could add this attribute to the class:

[Cmdlet(VerbsCommon.Select, "RadioButton", SupportsShouldProcess = true)]

The attribute determines the actual name of the cmdlet you’ll use in scripts (Select-Radiobutton).  The cmdlet needs an instance of AutomationElement to operate on, so that’s defined next:

[Parameter(Position = 0, Mandatory = true, HelpMessage = "Element containing a radio button control")]
public AutomationElement Element { get; set;}

Finally, I adapted some of the logic for my override of the ProcessRecord from this article on using UI automation.  The end result looks something like this:

protected override void ProcessRecord()
if (Element.Current.ControlType.Equals(ControlType.RadioButton))
SelectionItemPattern pattern = Element.GetCurrentPattern(SelectionItemPattern.Patern) as SelectionItemPattern;
if (pattern != null) pattern.Select();
//Put something in here for handling something other than a RadioButton
catch (Exception ex)
// You could put some logging here


Set-ExecutionPolicy RemoteSigned

When you first get started with PowerShell, don’t forget to run ‘Set-ExecutionPolicy RemoteSigned’ from the PowerShell prompt. If you try to run a script without doing that first, expect to see a message like the following:

File <path to file> cannot be loaded because execution of scripts is disabled on this system.  Please see “get-help about_signing” for more details.

The default execution policy for PowerShell is “Restricted” (commands only, not scripts).  The other execution policy options (in decreasing order of strictness) are:

  • AllSigned
  • RemoteSigned
  • Unrestricted

When I first tripped over this, the resource that helped most was a TechNet article.  Later, I found a blog post that was more specific about the execution policies.