If you’ve been reading my series of articles about using WPF from PowerShell and wishing I had started with the basics about what WPF is … you’re in luck. Following my series of posts, the PowerShell team has written their own series — with a much more methodical approach. Starting with an introduction to WPF and PowerShell followed by a great overview of how to use some of the WPF controls from PowerShell and how to handle WPF events , they have now moved beyond the basics of XAML and PowerShell to show you how you can make GUI a part of your PowerShell pipeline like I did with my Select-Grid post. With their most recent post, they explain how to run WPF in a background runspace and they promise tomorrow they’ll expand on that to “make controls in the background stream data and talk to the main runspace” — these two topics are what I was going get to next, so this frees me up to play with something more interesting ….

The PowerShell team has released the second CTP of PowerShell 2 and it’s got so much new stuff in it, that it’s honestly hard to know where to start, so this first post is just going to be a list of the things I find the most exciting.

STA Threading

You can run PowerShell in Single Threaded Apartment mode, which will let us create WPF/XAML and some neat UI tricks that we couldn’t do before.

Modules

Modules are … like classes. They export public functions, and can have private functions and variables… you basically import the functions into your runspace, so you can call them, and they can share data via variables and even other functions in the same module. This is really awesome, and will almost certainly improve a dozen or more of my scripts which I’ve been using as containers for sets of functions.

Events

PowerShell has support for events, including a whole set of cmdlets: Register-ObjectEvent, Register-PSEvent, Wait-PSEvent, Remove-PSEvent, Unregister-PSEvent, Get-PSEvent, New-PSEvent, Get-PSEventSubscriber which will, in many cases, seem extremely familiar to users of x0n’s PSEventing snapin.

Constrained Runspaces

I haven’t had a chance to test this out yet, but the word is that we can create constrained runspaces that limit access to commands, scripts, and language elements. I’m not sure if this lets you prevent access to part of the .Net framework, but it looks interesting in terms of running other peoples scripts.

Splatting Operator

When you’ve got an array, you can split it up and pass it to a function so each element in the array shows up as a separate argument to the function, so if you have a function foo can call a function bar and pass it all the arguments that get passed to foo, without needing to know what they are or how many there are. (in v1, you have to do things like this: iex "&'bar' $args" which just gets ugly).

Verbose, Warning and Debug streams

I haven’t figured out how to really do anything with this yet, but the release notes say that these streams now contain string messages, invocation information and even pipeline metadata like counts of how many times each command in a pipeline has been invoked — someone was just asking for this on the usenet newsgroup the other day …

Add-Type

There’s no help for this cmdlet, but it’s primarily a wrapper around the .net compilers (CSharp, CSharpVersion3, VisualBasic, and JScript, by default). However, it can also replace all the [Reflection.Assembly]::Load* methods so you can save some typing. I’ve figured out a couple of uses so far, and both are really useful:

Incidentally, there’s no help for Add-Type for some reason, but you can get basic information about how to use a cmdlet by running a command like this: (Get-Command Add-Type).Definition -replace "`n","`n`n" …

Well, the first alpha CTP release of PowerShell 2.0 is out, and there’s a lot of new stuff in it … but I won’t repeat the list from the PowerShell blog, because I’m sure you’ve seen it five or six times already. Instead, lets just skip straight to talking about one of the features we’ve been hearing about the longest: in PowerShell 2, you can create Cmdlets in script … bringing nearly full parity between whats possible in a C# cmdlet and what’s possible in script.

There are a few caveats still (Parameter Sets aren’t working yet, and neither is help, really), and a few surprises … there’s a few downsides to PowerShell script vs C# ... but in this particular context one thing that stands out is that in C# the BeginProcessing, ProcessRecord, and EndProcessing blocks are actually methods which can call each other, and as demonstrated in my tutorial for writing cmdlets that work in the pipeline, they can be recursive — without getting duplicate variables.

A sample Script Cmdlet

In the interests of being the first to publish an interesting script cmdlet and to continue my recent trend of talking about writing for the PowerShell pipeline, I’ve merged the logic of my script function and my pipeline cmdlet into a single sample script cmdlet for PowerShell 2.0 and it works great!

A few observations from the process, in no particular order:

• If you recursively call your cmdlet from within itself, you have to test for parameters using the new $CommandLineParameters.ContainsKey because parameter variables keep their values through recursion if you don’t explicitly pass a value.
• $CommandLineParameters.ContainsKey works differently in the Begin block where it will return $false for arguments which will get their values from the pipeline, than in the Process block where it will treat values which were passed as CommandLineParameters the same as those which were passed via the pipeline.
• If you want to see how your function behaves in a pipeline, you should make sure to test it at different points in the pipeline: at the front, in the middle, and at the end.
• Cmdlets are functions: they show up in the Function provider.
• Cmdlets are functions: they have to be dot-sourced before you can call them.
• Cmdlets are not functions: they are a single command Cmdlet which takes a name (which must have a – in it) and a couple of other parameters followed by a function script block.
• When you recurse by executing &($MyInvocation.InvocationName), that second invocation has an InvocationName of “&” ... so you can’t go any further (this might be a good thing, if you want to stop recursion at one level no matter what. If you want to go further, you need to put your commands into a string, and use Invoke-Expression.

A test case