Of course, the simplest thing to do is just stick that stuff in a DataGrid, so we’ll just whip up a simple WPF window. Yes, WPF of course. I can’t go back to Windows Forms, even for just for a simple example like this, but it’s basically the same except you have to set the DataGrid DataSource property instead of the ItemsSource … anyway, here’s the XAML:

Just add a reference to System.Management.Automation (it’s in the GAC: C:\Windows\assembly\GAC_MSIL\System.Management.Automation\1.0.0.0__31bf3856ad364e35\System.Management.Automation.dll) and then in your window’s constructor (or wherever you like), put this code:

That’s it. We’re done.

And now for something slightly more interesting

What about if we also wanted an easy way to spot the biggest memory consumers? We could start by sorting the processes by the WorkingSet, and pick just the 15 worst offenders. But let’s also add a chart to visualize just how bad those top offenders are. In WPF, this is simple: I’m going to use the free amCharts in my example, but you can do the same thing with the free visifire or visiblox charts, or the (commercial only) Telerik RAD controls … etc. All of those work in both WPF and Silverlight (and all three of the “free” ones have commercial versions).

Of course, this got a little more complicated. We needed to put the controls in a panel of some sort (I chose to use a Grid mainly because it automatically causes the scroll viewer around the DataGrid, but that forces us to specify the ColumnDefinitions) and the PieChart needs bindings for the value and title of each slice. You’ll notice I set the ItemsSource of the DataGrid and the SlicesSource of the PieChart to “{Binding}” (side note: why can’t they just use “ItemsSource” like normal people?) ...

Setting the sources to {Binding} causes them to just look at their data context, so now in the code behind, I can bind them both at once by just setting the DataContext of the window (try that in Windows Forms).

That’s all there is to it. I can attach my solution after I give my presentation if people want it, but there’s really nothing else in it (so far) except the references to the amCharts and System.Management.Automation …

Also, the PowerShell Community is running a survey about the possibility of a PowerShell convention, and what you’re interested in seeing at one… it’ll just take a moment

Recently I’ve picked back up on that project, and am just about ready to release what I hope will be the last “pre-release” of PoshConsole before I declare it to be “beta” quality and start doing more regular releases.

The coolest features of PoshConsole, the ones that are really revolutionary, involve exposing the WPF surface to scripts and cmdlets so that you can actually have graphical output in the console — not popups, and not just for fun… but stuff like putting bar graphs behind the size columns in Get-ChildItem for folders, and the memory columns in Get-Process, etc… anyway.

So I’ve been writing a few scripts to show off the possibilities of PoshConsole, and was thinking about even posting them on the PoshCode.org PowerShell Script Repository, but I wanted a way to make clear that they’d only work in PoshConsole.

A little investigation later, and it was clear that PowerShell has a built in feature for this: #requires -ShellId PoshConsole … except, it doesn’t work. Actually, it doesn’t work for two reasons:

1. PowerShell always ignores #requires -ShellId Anything

1. No other PowerShell host implements ShellId as far as I can see

The ShellId is a read-only property of the RunspaceConfiguration, so to implement it in your PowerShell host you have to create your own RunspaceConfiguration class inheriting from the abstract base class. The problem is, there are some expensive side-effects:

1. You have to configure the available .net Assemblies, Cmdlets, Format files, Initialization Scripts, Providers, Scripts, and Type files …
2. Having your own ShellId means you don’t inherit anything from PowerShell.exe (like for instance, the ExecutionPolicy)

1. Some cmdlets just don’t seem to work (Add-PSSnapin is just failing on me with “Object reference not set to an instance of an object”)

So … to sum up: PowerShell ignores #require -ShellId, and I can’t find another host (including Microsoft’s “Graphical PowerShell” and the latest and greatest PowerShell Plus Professional) that bothers to set the ShellId. Can anyone tell me a reason why I should bother with this?

Oh, and, can anyone give me some information about why Add-PSSnapin might be failing when I do set the ShellId?

ShellId IS too big a burden.

After further investigation, it turns out that the reason Add-PSSnapin fails is because it uses a method AddPsSnapIn which is part of the RunspaceConfiguration (that you had to create yourself to set the ShellId), and you can’t implement that method (in fact, you can’t seem to override it with “new” either, I’ll have to look into that a little more).

In any case, the method has to return a PSSnapInInfo object, and since there are no public constructors for PSSnapinInfo objects, you’re sore-out-of-luck. It appears you would literally have to reverse engineer the whole “PSSnapin” system and create your own cmdlets and functionality around it to try to keep your host compatible with the main PowerShell. No wonder nobody’s done this…

I guess I’ll just go back to using Microsoft.PowerShell as my ShellId, I don’t know what I was thinking.

Loading the banner from an external XAML file means that users can configure their own startup banner and make it look however they like, but it broke our default banner. The startup banner we’ve been using has a logo and some text which are all defined in pure XAML and uses several fonts which we had embedded in a FontLibrary.dll resource assembly. It worked great as long as the XAML was defined in the application, but as soon as we removed it to an external file and loaded it in using the XamlReader.Load method, the fonts all went to the fallback default fonts instead of our embedded ones.

Normally this might not be a big deal, but since our logo is based on the “Q” in a Quake-like font … it looks really lame without fonts. Apparently, when you load external XAML, it can’t use the Font Resource Library resources. At this point, I can’t seem to find anything to indicate why this is the case, but I suspect it has to do with the fact that the external, loaded XAML only has partial trust, and since the font is in an external assembly instead of embedded in the partial trust content, it can’t get to it. However, it might be simpler than that: it might just be that the base URI for the externally loaded XAML is an actual file location rather than one of the pack://,,,application/ type URIs, so the slightly odd font path doesn’t resolve.

In any case, I found a way around it, which is of course, why I’m writing all of this down. If you declare WPF resources in your project, you can inject them into the WPF objects loaded from the XAML to make them available to them. So for instance, I have a font called “Quake” in the FontLibrary assembly. I can declare it as a resource in my application’s XAML (at the app level, window level, or wherever).

The font in that style gets resolved in full trust with the pack URI, and it works fine when used from my application. Having created that, I can do the same thing in the external XAML files, and apply the style to the text as a DynamicResource … and even feel free to override parts of the style if I want to. For instance, even though the style might specify a FontSize, if I refer to the style on this text block and specify my own FontSize, the one that’s on the TextBlock (or Paragraph, or Run, or whatever) will be used. Now, we’re not quite done yet, because although they look the same in source, the fonts won’t resolve properly in the externally loaded XAML.

However, because the style is specified as a dynamic resource rather than a static one, I don’t have to define that resource at all in that XAML file, but even if I do, when I load the XAML into my application, I can simply set it’s resources from the resources that I’ve loaded in full trust and with the pack:// base URI... In my case, I have actually defined several fonts as resources on a Document element, so I just copy them all into the element I read in from the XAML file:

And that’s it:

We have been trying to find a way to incorporate the colored and even bold/italic formatting in a way that would be compatible with the existing format-* cmdlets, and we’ve even looked at replacing out-default with a cmdlet that would be compatible with the default PowerShell host. But today I finally locked in on the import of this post on the PowerShell blog. It’s just not possible.

The format cmdlets (Format-List, Format-Custom, Format-Table, Format-Wide) output data in the form of undocumented .Net objects which are “subject to change without notice,” and are therefore basically useless. Of course, that means that if you want to replace Out-Default you have to not only replace the output, but you have to replace the formatting cmdlets, and of course the Update-FormatData cmdlet too — in fact, you have to either parse the largely undocumented format data files, or create some replacement for them to allow users to specify formatting for types you haven’t thought of…

All of this amounts to what many of you probably already knew: it’s a lot of work to create a complete PowerShell host, but it’s at least as much work to create a replacement PowerShell formatter.

This is actually a bit scary, because you can load sort-of … anything To prove it (you’re gonna love this … I should take a video, really, but it’s time for bed, so this will have to do): check this out Beat that!

So yeah, I have this control written from an earlier project which creates a task list with live preview images. When I say “live previews” I mean actually live, like on the Vista Alt+Tab: if there’s a video playing, you can watch it in there (of course, it dies a horrible death on XP, but I have other code for that).

As a side note the TaskBar2.panel stuff is from the TINS release I made months ago, there’s several fun .panel files in there … but you have to load a bunch of the TINS assemblies first, I didn’t distinguish which ones, I just did:

Of course, in .Net 3.5 the RichTextBox has the ability to go ContentEnabled="true" which should allow those things to be actual controls you can click to switch active task, right-click to get a task menu, etc (although I haven’t tried that yet). We might just have to upgrade

Anyway, it’s past time for bed, so I’ll preempt complaints about how this isn’t ready for release yet with this quote:

I don’t have to take this abuse from you; I’ve got hundreds of people waiting to abuse me. — Bill Murray, “Ghostbusters”

Now, there are a few other hosts out there, but with PowerShell Analyzer seemingly swallowing up PowerShell IDE and going the fifty dollar route … as an open sourcer and contributor to the PowerShell Community Extensions it seemed to me that this couldn’t be that hard, so I started looking for an open source implementation of PSHostRawUserInterface and couldn’t find one. I mean, there are a couple of implementations out there, but essentially they are the PowerShell Remoting interface (which actually runs inside PowerShell.exe, and thus doesn’t seem to implement anything itself) and a half-implemented console block from a Japanese file manager called kuon …

So, being myself, I stepped in an implemented it in the weirdest way I could think of: on top of a WPF RichTextBox. Yep, that’s right. I’ve made myself a ConsoleTextBox which subclasses the RichTextBox and handles keyboard input etc to behave … roughly … the way a Console should.

It’s far from finished, but it is working, so this is by way of announcing the first public alpha release of PoshConsole! The vast majority of PowerShell scripts will run without a hitch — the only time you’ll have problems is with secure string input (eg: passwords), with direct raw buffer interaction, and with running “legacy” console applications — it does not yet redirect standard input/output/error.

One small tip: if you have the PowerShell Community Extensions installed, you’ll want to remove the alias they set up to pipe help through “less” ... because less is a legacy console app — you won’t get any help at all.

Technorati Tags: PowerShell, Scripting, Windows, Command Line