Yesterday I came across a very strange bug which was causing Visual Studio to lock up after a few (30?) seconds every time I opened an ASPX file for editing. I even uninstalled a few VS addons I thought might have caused it… but that didn’t help (I’m reinstalling Resharper as I type this).

After much frustration and a couple of Bing searches … it turned out to be a problem with MS Office 2007 components. This was a bit of a surprise, since I do not have Office 2007 installed. However, I do have Office Communicator and Live Meeting which are Office 2007 products — and I had just installed Office 2010, which may have actually caused the problem.

Rinat Abdullin wrote about the problem earlier and there’s a thread on StackOverflow which is at least related.

Basically: you get “beeping” when you try to click in the text editor for aspx, or on the Solution Explorer … (sometimes, but not always, Visual Studio will actually be marked as “Not Responding” by Windows) – and, when this happens, you look in your TaskManager and see this Setup.exe process.

This one — in your %CommonProgramFiles% or %CommonProgramFiles(x86)%:
C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\Office Setup Controller\SETUP.EXE

Shutting down Visual Studio and then running that installer “as administrator” manually has solved the problem for me. I just hit “Repair” and that was that. Others (including Rinat) have said they had to reinstall Office — I suspect that probably depends on whether or not you had Office 2007 installed in the first place.

There are lots of examples in there in C# (no other languages), and honestly, some of them ought to make it into PSCX or some other project where people could grab pre-compiled versions

• A Template for creating PSProviders, and a sample PSProvider (for Access databases).
• A sample of participating in Transactions (a set of “transacted comment” cmdlets for creating comments that go along with a transaction).
• Example cmdlets: Select-Object, Select-String, Get-Process, Stop-Process
• Dealing with issues with Serialization in PowerShell
• PowerShell Eventing:
  • Deriving from ObjectEventRegistrationBase to create Register-FileSystemEvent
• Receiving notifications from PowerShell Events on remote computers.
• Hosting APIs, including (among others):
• Restricted runspaces
• Runspace pools
• Remote runspaces (and remote runspace pools)
• Running commands in parallel or sequentially
• Calling Cmdlets and passing parameters

• Reproducing the default PowerShell.exe output

Honestly, if you’re a developer that’s been wondering about learning to code cmdlets, or host PowerShell as a scripting engine, now’s the time.

The first tool out of the gate, of course, was the Windows API Code Pack for the .Net framework. A nice library that makes it simple to write applications that take advantage of new Windows Vista and Windows 7 features like Libraries, Task panes and jump lists. Of course, that library has a major problem: it’s got an ugly and confusing license. Rather than using one of the standard Microsoft Open Source Licenses, the team used a license from the dark ages that features the vague “Excluded Licenses” clause and other ugly terminology.

More recently, Microsoft has announced a Platform Update for Vista which is intended to allow Vista to run most applications designed for Windows 7. The Platform Update is a set of runtime libraries which includes the Windows Ribbon control; Automation Manager Library; DirectX updates for hardware acceleration; DirectCompute for hardware-accelerated parallel computing support; the XPS printing library; the Windows Automation API; and the Windows Portable Devices Platform, which standardizes data transfers across apps and portable devices. This important package will be made available through Windows Update (and applications will be able to prompt you to download it) and it is in public beta with more information on the Windows Team blog. A couple of pieces of that will be made available for Windows XP; particularly the Automation API, which allows accessibility tools and test automation tools to access Windows user interface in a consistent way — this will mean that the next release of WASP will work flawlessly across Windows XP, Vista, and Windows 7.

Also in the works is the Remote Desktop Connection 7.0 (RDC7) client for Windows XP and Windows Vista to allow these older clients to take advantage of all new server features in Windows 7 and Windows Server 2008, including multi-monitor support and media redirection. There’s more information about that on the Remote Desktop team blog.

And finally, the release candidate for the Windows Management Framework (WMF) is also available. The WMF will include WinRM (Microsoft’s implementation of the WS-Management spec), PowerShell 2.0, and BITS for Server 2008, Windows Vista, Server 2003, and of course, Windows XP. This means that if you’re on Vista, or still using Windows XP, you can now upgrade from the PowerShell 2.0 CTP 3 to this release candidate and expect remoting to work!

All of these should be seeing final releases in the very near future, and some of them possibly by the time Windows 7 is released to the public.

Related articles by Zemanta

• Make a bootable USB installer for Windows XP, Vista, 7 with WinToFlash (downloadsquad.com)
• Microsoft, Intel build fast, efficient Windows 7 machines (infoworld.com)
• Free Windows 7 Upgrade (techblissonline.com)
• Users abandon XP for Vista, Windows 7 (infoworld.com)
• Fun with PInvoke and Aero Peek (huddledmasses.org)
• Microsoft: Windows 7 not affected by latest flaw (news.cnet.com)

An introduction to PowerBoots

Please excuse me if I start by just copying the basic ideas of the Shoes Tutorial, but I figured that since PowerBoots is inspired by Shoes, that was as good a place as any to start. PowerBoots (or just “Boots”) is a PowerShell 2.0 module with functions for writing Windows Presentation Framework (WPF) applications in the PowerShell scripting language. You should get the latest version of PowerBoots before continuing, and install it by putting the “PowerBoots” folder in one of your “Modules” folders (list them by typing $Env:PSMODULEPATH in PowerShell v2).

Don’t forget to start PowerShell.exe with the STA parameter (This is no longer required in PowerBoots 0.1).

Did I hear someone ask what is WPF? It was introduced as part of .Net 3.0 (and vastly improved in .Net 3.5), so you can expect to find it preinstalled on computers from Vista on, and of course you can download and install it on XP if it’s not already installed. The only thing you really need to know about WPF for the purposes of this tutorial is that it is the new GUI toolkit for .Net, and that it is container based — you put elements into other elements to control the layout, rather like HTML and Java Swing… you can pick up the rest as we go along.

A simple Boots program

I’ve recently changed this first example to pass a script block to the content instead of using parentheses, because although PowerBoots supports running in an MTA PowerShell host, the only UI-creation command that is MTA-safe is the New-BootsWindow command. All of the “new” functions must then be inside of a scriptblock which is passed to the New-BootsWindow cmdlet and executed on that STA thread. You can use parenthesis ( and ) as a container instead, but that requires the host to be in STA threading mode (run: PowerShell -STA) so the controls can be created:

This first example is a bit uglier than the Shoes syntax, so lets see if we can’t clean it up some. The -Content parameter is positional, so the first non-named argument you pass will be used for that. The same is true for the -Children parameter of panels, and in fact, each of the other similar parameters: Items, Blocks, and Inlines.

We have used a function New-BootsWindow which has an alias Boots. Boots takes all the same parameters as the Window function mentioned previously, but it uses slightly more useful defaults, and has a few other major benefits as well, the first of which is that it automatically “shows” the window, and the second is that it supports an -Async parameter which allows the window to come out in a new thread so that you can continue using PowerShell while the window remains alive and responsive. There is one catch: New-BootsWindow cannot take it’s content on the pipeline (the old function, now renamed “Out-BootsWindow” can take pipeline content, but is a script function, and requires -STA mode) — you have to specify it as a ScriptBlock. So now that we know this, we can rewrite our first example like this:

Just for the record, the simplest Boots program would just be a simple popup dialog to put some text in a Window, like: Boots { $msg } …

We can put controls in a stack

StackPanels are awesome. So are WrapPanels. Try that code with a WrapPanel instead of a StackPanel and see what the difference is. This brings up another point: those positional parameters we mentioned earlier: Content, Children, Items, Blocks, and Inlines, are also set to accept the value from the pipeline. Not only that, but they are intelligent about whether or not the content model accepts multiple items! So we can actually rewrite that script like this, and get the same results:

Now we’re really onto something! For most of the rest of these examples, I’m going to stick with the former syntax, because with the indenting and parenthesis, it’s much easier for you to follow, especially if you’re not already familiar with WPF. For instance, check out what this does:

Ok, lets see some formatting

To scoot the buttons out from the edge we can use margins or padding: margins go on the outside of containers, padding goes on the inside.

So you see, the pink background is on the StackPanel, which has a (white) margin around it. If you wanted the whole background of the window to be pink, you would need to set the background of the Window instead of the StackPanel.

Time for some artwork

In Boots, everything always starts out white, and you must position things based on the container. You can see that the Margin can be specified as a single value as in the previous example, or as separate values for Left, Top, Right, Bottom. Oddly, to satisfy PowerShell’s type-casting, you have to quote them so they’re a single comma-separated string, instead of four separate values.

Some more advanced drawing

We use a Canvas for this because it can contain multiple items which are all absolutely positioned. Unlike other containers, it doesn’t automatically expand to contain it’s children, so you typically have to set it’s size.

We also have to set the Stroke and Fill. These are the two colors that make up every object, if we don’t set them, they default to white. The StrokeThickness controls the line thickness. Notice that we positioned the Rectangle by using the Margin, and positioned the arrow, which we built using a Polygon, based purely on the x,y coordinates of the points. The available shapes are Ellipse, Line, Path, Polygon, Polyline, and Rectangle. You can, of course, make any shape you want to with the Polygon.

There are other more advanced shapes available in external libraries, and we can even do 3D, use gradient or image fills…

We can even get images straight off the web

Boots loads the image on a background thread, and caches it in memory, so the window will show up and be responsive while you’re waiting for the image, and because we’ve specified -Async, you can actually continue using PowerShell while the image loads. Note: it will load much faster the second time you run that script.

Typography

PowerBoots doesn’t try to create a full set of typography-specific top-level elements the way Shoes does, because we are based on WPF, which has a far more powerful typography system available than any we’ve ever used. So instead of having a bunch of named elements like banner, and title, and caption, and para and whatnot, we have controls based on how much text you want to put in them, and how much formatting you want to apply: Label is simplest, TextBlock supports limited text formattings, and FlowDocument supports full rich content. And of course, Hyperlink supports clicking

For the typography elements, the content model changes a bit. There are basically two types: Inline and Block elements. The TextBlock Content Model is similar to that of a FlowDocument, it is actually a type-restricted “Items” container. Instead of being able to have anything as content, it can only contain Inline flow content elements such as AnchoredBlock, Bold, Hyperlink, InlineUIContainer, Italic, LineBreak, Run, Span, and Underline, and it will create a run automatically if you just put a text string in it.

Note: If you want support for the full document model (which allows Paragraphs and Lists), you need to use a FlowDocumentReader, FlowDocumentPageViewer, RichTextBox, or a FlowDocumentScrollViewer ... there’s lots more information about those on msdn.

Events

If you were paying attention to that previous example, you’ll notice we just introduced event handling. Event handlers in PowerBoots are specified in much the same way that Properties are. Their parameter names always start with “On_” and they take a script block. The Hyperlink element in a WPF window doesn’t automatically open a browser (because you can use it to change “pages” in a WPF application), so to make simple web links work, you have to handle the “RequestNavigate” event as shown above.

In order to update your user interface when an event triggers, you’ll need to have a variable that points at the control(s) you want to affect. You get a $this variable for free which points at the object that caused the event (eg: the Hyperlink in our previous example), but otherwise you need to handle this yourself. You can do that one of two ways: you can set a variable the way you normally would, and then use the variable in the form, or you can specify the variable name using the -OutVariable parameter. Personally I prefer the latter, as it messes up the flow of code less, but it has the downside that the output variable is always an array, even when there’s only one item.

I’ve made these examples slightly more complicated than they had to be to demonstrate some best practices. When the Window is closed, the Out-Boots function returns the $BootsOutput variable — so if you want to output something from your gui, you need to set that variable. You can, of course, access global scope variables using the scope prefix $global:variableName, so you can set many different variables which you read later in your script. The catch is, sometimes the variables have to be explicitly set to script or even global scope in order to refer to the same variable in all of the event handlers…

However, if you want to have this block of code actually output something into the pipeline, you’ll always want to use the $BootsOutput variable. You can do that directly, the way the example above does, or you can simply use Write-Output! Inside the Out-Boots function, he Write-Output cmdlet just appends to the $BootsOutput variable … so it works pretty much exactly the way you would expect it to.

The first example outputs just the count of how many times you clicked. The second outputs a series of numbers from 1 to however many times you click. It’s your choice of how to work with it.

We can have fun with colors

Boots gives you access to all the capabilities of the Windows Presentation Framework, but in some cases that comes at a cost, because we haven’t simplified their composability. So we have RadialGradientBrush and LinearGradientBrush, but you have to specify the GradientStops etc …

We also have

So what does an InputBox look like?

Well, the simplest possible input box is just a TextBox, with the Width set (if you don’t set the Width, a TextBox will adjust to fit it’s contents, which can be really distracting). All you need to do is this:

Of course, the problem with that is that it pops up this rather confusing window, when what we really wanted was a prompt, and an “Ok” button, and some event handling to make the thing behave the way we expect it to. So lets try our first complicated form.

I’ll warn you ahead of time of one thing I’m going to do here. I’m using the “Border” element to apply a colored border to the StackPanel (because it doesn’t have it’s own border parameters), but then I’m also using the WindowStyle and AllowsTransparency properties to remove the normal window chrome, creating the bare little popup you see in the screenshot. I handle the mouse down event on the main window to allow the user to drag the window around by clicking anywhere on it (except in the TextBox or on the Button, of course). Now it looks slick, and —you know— it works!

Hopefully you can follow that, although it’s obviously over the top . We handle the KeyDown event on the TextBox (if the Key is the Return key), and we also handle the click on the Button. In both cases, we’ll write out the text that was entered, and use the special $BootsWindow variable to close the window. We also handle the Load event for the window, to make sure the focus is on the TextBox, so you can just start typing.

A final example

I’ve got quite a few more examples I want to show off in part two of this tutorial, but to get you thinking about ways to integrate this with your routine tasks, and give you some ideas of what you can do with what you know already, let me give you this example of browsing photos, with a visual indication of how big the image file is. Of course, the point is that you could be visualizing, you know … anything.

Notice that I had to manually handle the concept of a double click, because StackPanels don’t have a Click or DoubleClick event, just MouseDown and MouseUp. I could have stuck the stackpanel into something that does, but there’s really no need. Also, the [Diagnostics.Process]::Start is the equivalent of typing the name into the run dialog. I’m just executing the jpg, which makes it open in the default editor. It’s just a sample, after all.

End note

The current version of Boots does not add threading support, which means that when you run something through Boots, execution of your script stops until the window is closed. You can get around this somewhat in various different ways, but future releases will support running the WPF window in a separate thread, and even communicating to it … at the expense of a slightly different syntax. If you need that functionality, feel free to let me know … I could use some motivation.

I hope you’ve enjoyed this tour through PowerBoots, and will be able to start applying it for fun and profit.

looking for a … guide to putting together an advanced function that is visible and usable every time I start Powershell. By visible I mean that when I do a ‘get-command’ I want my [advanced function]s to be listed alongside all the regular cmdlets. What makes that possible? ... what do I need to do to make that happen? Whats the difference between an [advanced function] and a module?

There are lots of articles on the Microsoft PowerShell team blog about both topics, but it seems there’s not really been any sort of step-by-step written, so I posted this to the newsgroup, and since the person who asked the original question said he found it useful, I figured I’d share it here…

An Aside: Advanced Functions vs. Modules

Advanced functions and script modules are unrelated topics. A script module could have nothing but old PowerShell 1 -type functions, hypothetically, it could even not have any functions at all. Advanced functions can be defined in a plain .ps1 script, in your profile, or by typing them in on the command-line, etc. The two things are essentially unrelated except for both being new features in PowerShell 2.0.

How To write an Advanced Function

Step 1: Have something you want to do in a function.

I can’t emphasize enough how important it is that you should have a specific goal here. Writing a script for a specific purpose is much easier, because you don’t have to think about whether or not specific features are necessary, etc.

For the purposes of this example, I want a function to start executables and return me the process object (so I can wait for it to finish, or whatever). I will call it Start-Process.

Step 2: Write a first step for the logic of your function.

Be sure to specify the parameters using the function Name{Param(...)} syntax rather than function Name(...){}, then you will be able to easily convert it to an advanced function by adding [CmdletBinding()] on the line right before the Param like this:

Step 3: Start writing documentation and auto-help, including your parameters.

Step 4: Exploit advanced features by marking up your parameters.

In my case, I had a look at the signature of the start method by running [Diagnostics.Process]::Start.OverloadDefinitions and discovered that it can take credentials too. So I wanted an optional credential parameter. I specified it without a position, and made it part of a non-default parameter set.

I also wanted the params parameter to just take any additional parameters which I pass to the function, and pass them on to the process that I’m starting.

Finally, I wanted the “App” parameter to be able to come from the pipeline. Specifically, I wanted to be able to pass the output of Get-Command or Get-ChildItem to it. In order to enable that, I defined an alias on it to the relevant properties of the objects which come from those two commands

Hopefully you’re getting the idea of what’s possible here …

Bonus Step: Make the function be automatically defined

To be honest, there are a lot of ways to do this, here’s a few:

Option 1. Define it in your Profile.

Include the full text of the function in your Profile.ps1 script or Microsoft.PowerShell_profile.ps1 … just run notepad $Profile and paste the whole function in at the top, then save.

Option 2. Dot-source it in your Profile.

Save the function into a script file, e.g.: “StartProcessFunction.ps1” in your DocumentsWindowsPowerShell folder (next to your profile script) then put the line: . StartProcessFunction.ps1 into your profile script to dot-source it. Using the dot causes the script to be loaded into the context as though you had put the contents of the script in, instead of the dot-source line.

Option 3. Import this function from a script file.

This is basically the same as Option 2, except instead of “.” you can use Import-Module. The Import-Module cmdlet, when used on a file with the .ps1 extension, is basically the same as dot-sourcing it, so there’s not a whole lot of benefit over dot-sourcing in this case.

Option 4. Put the function in a module.

You should only do this if you think you might want to add additional functions to the module. For instance, lets say you want to write a few other functions for working with process objects. If you put them together in the same module (say: “ProcessUtility”) they can share script-scoped variables or private functions, and can be identified as being part of the same module using the Get-Command -Module ProcessUtility command.

If you just have the single function, there’s really no point in changing it to a Module, but I’m not aware of any downside, either.

Option 4a. Make a module by just saving as a .psm1

All you do is save the function into a module file, e.g.: “ProcessUtility.psm1” in your DocumentsWindowsPowerShell folder and then put the line: Import-Module ProcessUtility.psm1 into your profile script.

Option 4b. Make a module folder.

This is by far the most extensible way to create modules. You paste the function into “ProcessUtility.psm1” and then save it into a folder “ProcessUtility” which must be created in one of your module folders. You can figure out where the module folders are by checking $Env:PSMODULEPATH — the normal spot is your DocumentsWindowsPowerShellModules.

Once that’s done, you can import with the simpler command Import-Module ProcessUtility without any extension.

The nice thing about creating the folder is that you can put any additional resources in that folder with it, and get at them using the $PsScriptRoot to define the folder. You can even add additional functions by putting them in separate files (which you can Import-Module from the main file, or you can define using a .psd1, but that’s another article).

Just for fun, I’m going to rehash an earlier post about updating windows to show how you can go about this using PowerBoots, and hopefully show that it’s a little easier (and a lot more async). Compare and contrast the code in this article with that one, just for fun.

This works with any version of PowerShell

Unlike the original article, most this code (except where explicitly mentioned) works on either PowerShell v2 with PowerBoots, or PowerShell 1.0 with PoshWPF, a snapin that is part of the PowerBoots module but is also released separately… Also, unlike those previous posts, this does not require you to be running PowerShell.exe with the -STA switch, since the New-BootsWindow cmdlet takes care of threading for us.

The simple splash screen

This is, of course, not a great example of why you would want to use XAML, since it reads virtually the same as it would if you wrote it in PowerBoots (if you were on PowerShell v2):

The big difference, of course, is that this is fully aync, so unlike the splash screen in the original post, we don’t have to do any tricks to get it to render, and we are able to add a MouseDown handler so you can drag the splash screen around while you wait for it to go away…

And now, for something completely different

Let’s skip over the very useful information I already wrote about the properties you can set on the “Window” object in WPF (all of which are parameters to New-BootsWindow, by the way) and cut straight to the second example … I’ve tweaked an old WPF sample I had and ported it to PowerShell, and now, adapted it for PoshWpf ... the xaml file is here and I’ll show you the code just as soon as you take a look at the screenshot (trust me, the code will make more sense if you’ve seen the output):

So basically, the UI is defined in a href=‘http://HuddledMasses.org/wpf-from-powershell-updating-windows/clock/’ rel=‘attachment wp-att-528’>that xaml file, and all we need to do in the script is update the time, update the CPU bar, and update the RAM bar…

Please notice the content block

PowerBoots passes the window object itself into the content scriptblock, and the content block must output the content you want in the window. Of course, if you’re loading a fully defined window in XAML, you don’t want to change the Window’s content, but you have to return something, so you should just return … the content that’s already in the window. Ie: $Args[0].Content

One other point, for those of you who are going to become XAML masters. In PowerBoots you can define just the styles and templates as resources in a separate XAML file which you can load with the Add-BootsTemplate, and then you can still create the UI in XAML or useing PowerBoots syntax. In my case, this XAML was edited using kaxaml (it could have been Expression Blend, or Visual Studio), and kaxaml doesn’t make it easy to separate out resource files, so I just left it all in one file:

So, meet Register-BootsEvent

If you’ve read the previous PowerBoots articles, you know that you can specify events as parameters to the PowerBoots functions, like -On_Click or -On_MouseLeftButtonDown, but in the case where you’re loading XAML, you can’t specify events in the XAML (WPF’s XamlReader won’t read XAML with events on it, or even with the Class specified, because you can’t use the associated code file anyway).

In any case, what I’m adding to the next version of PowerBoots/PoshWpf are two functions:

1. Find-BootsControl takes a boots window and the Name of a control, and will (try to) find the named control. Of course, for that to work, you need to know the name of the control (your best bet is to name it yourself, but in the next version I may also issue names for elements as they are created if you don’t specify the name).

1. Register-BootsEvent takes either a control, OR a boots window and control name, plus an event name and a ScriptBlock. If you pass the window and name, it calls Find-BootsControl to find the control; once it has a control, it registers the ScriptBlock as a handler for the specified event.

For now, both of these require that you’ve assigned a name to the control, but I’m working on setting things up so controls would be automatically named (based on their type, as with the old WinForms designer: like Button1, Button2, etc.), or allowing an XPath-like selection without named controls. In any case, this will work nicely for generating event handlers for WPF imported from XAML, and you can even specify the element directly (ie: if you don’t specify the -Name parameter, the event will be hooked on whatever element you pass in) so that last block of code can be written like this in the next release:

I’m still thinking about the best way for me to expose this in PowerBoots, because the problem is that attached properties can get attached several ways, and not just on direct children of an element. So I wanted to show you a way that you can do it for now so you can at least use the DockPanel effectively:

A better way …

Here’s what I’m thinking about for the next release of PowerBoots (you can take this and use it now, if you like it, but I’m really looking for, uhm … better ideas). Basically, I have written a function: Set-AttachedProperty, which takes an attached property and a value, and passes through the element on the pipeline. You may want to use this in conjunction with the module I published awhile back for creating type accelerators, because it lets you run a line like this:

Which will let you substitute [DockPanel] for [System.Windows.Controls.DockPanel] … and of course, you can use it for all the types you want to use attached properties from, and it’s a real lifesaver if you need to use a bunch of them. Of course, in this particular example, we really only need to use a single attached property, so it’s enough to define that property ahead of time:

Then you can use the Set-AttachedProperty function through an alias sap, and rewrite that huge block above like this:

Pretty slick, right? And it will even print out the list of values in the error message if you invoke it with an invalid value against an enum property like dock: sap $DockProperty "" … The problem I have with it is that you have to predefine your $DockProperty variable, and you can’t just define it against the root class. So I’m trying to find a way to tweak the dynamic property generation to make it so that the pipe into | sap $DockProperty Bottom can just be a parameter to the original element: -Dock Bottom … if I can’t find that, in the worst case scenario, I’ll just add an -AttachedProperties parameter with a hashtable of $DockProperty,“Bottom” or something … what do you think?

In any case, here’s the sap function, for now, and remember to use it as part of the pipeline:

This release of PowerBoots is the most exciting release software I’ve cranked out in awhile. It finally has almost all of the features that I have thought of so far (we’re still missing proper support for attached properties).

• You can create pretty much any WPF element, including ones I haven’t thought of adding yet (use Add-BootsFunction to add a new assembly or a single type).
• You can create graphical user interfaces from PowerShell 1.0 all the way to the latest PowerShell 2.0 CTP.
• You can create your WPF GUIs -Async in their own threads, or inline in PoshConsole, or as synchronous dialogs that return values when they close.
• You can capture screenshots of your UIs (eg: generate .jpg charts from Visifire). You can even do so without displaying them!
• You can take advantage of XAML Data Templates to generate graphical representations of any objects in the PowerShell pipeline.

• You can add to, or modify your running GUIs from the command line.

You can read the “and much much more” between the lines right?

Breaking Changes and New Features

The big new thing in this release is that I’ve added a compiled module (PoshWpf) which contains several cmdlets, and gives us some major new functionality in exchange for a break in the syntax. The syntax change is pretty simple, really, and the new threading functionality (and PowerShell 1.0 support for the cmdlets) is awesome (if I do say so myself) .

New-BootsWindow replaces Out-Boots

New-BootsWindow is a compiled cmdlet, and in addition to all of the features already present in the now deprecated Out-Boots, it features a few important new features. Incidentally, I’ve actually left the old Out-Boots function in the code, just in case, but I’ve renamed it to Out-BootsWindow, and changed the “Boots” alias to point at the new New-BootsWindow.

ScriptBlock Content

The biggest change to your scripts is going to be a change from piping objects into Out-Boots, to creating your objects in a scriptblock parameter to New-BootsWindow. This allows the script to create the UI elements entirely within the new thread. Since we’ve switched the “Boots” alias to point to New-BootsWindow, anything you used to write like this: ... | Boots you should now be able to write like this: Boots { ... } and get the same result. Additionally, to make the syntax of our little DSL just a little bit slicker, I now allow you to pass scriptblocks for just about everything (particularly for the main content parameters). An example that looked like this, before:

Can actually end up like this, now (and produce the same output):

The Async Parameter

If you specify -Async, the new popup window is spawned in a new thread, and all of it’s events etc. are handled on that separate thread. This is actually what happens anyway when you run New-BootsWindow from a host that’s not running in STA mode, but if you don’t specify -Async, we fake the synchronous result so that you can use Write-Output within a dialog to prompt and get a result “returned” from New-BootsWindow. The cool thing about -Async is that not only can you continue using your console, you can run additional windows, and you can even use the new Invoke-BootsWindow cmdlet to run scripts within that window’s thread so you can change the GUI content, etc.

The Passthru Parameter

The -Passthru parameter causes the New-BootsWindow to output the window object that it has created to the pipeline. It’s really only useful when you also specify the -Async parameter, since otherwise the window will be closed before you can use it. Furthermore, because it’s a UI element, you can’t really do very much directly on the Window object without the use of our other cmdlets

The BootsWindow Collection

When you create a New-BootsWindow, the PowerBoots module (or snapin, for v1 users) tracks the window for you, so you can get ahold of it again later to run scripts against it, take screenshots, close it, etc. To enable this we have three new cmdlets:

• Get-BootsWindow returns the windows, and supports filtering by title or index.
• Remove-BootsWindow will clear the list of windows that have already been closed, when called without parameters, or will close (and remove) windows that are still running if you pass a specific window, index, or window title.
• Invoke-BootsWindow lets you run scriptblocks in a specific window’s thread

• Export-BootsImage lets you take a screen capture of the contents of a window (or of a specific control)

Add and Remove Templates

There are three new cmdlets for managing XAML source files. Add, Remove, and Get BootsTemplate. These allow you to specify additional XAML files (beyond the default.xaml), and those templates are always automatically loaded into each new window, so you can specify styles, resources, data templates and even new WPF Templates (I’ll throw up an example using the ones from WPF Themes later this weekend).

Download and Source now hosted on CodePlex

Well, that’s enough for the highlights for now. I’ve included the first blush efforts of a ps1xml format and data types files (which get loaded automatically with the module on PowerShell 2, but not v1), and I haven’t yet written up the help files for the compiled cmdlets. Look for more help and examples and maybe even some cleaned up sample videos over the weekend. Please file any problems you have as bugs on Boots.CodePlex.com, where you can find the latest release.

I do want to point out that I’ve left the version number at 0.1 … I really want to add some explicit support for attached properties, and I’m sure I’ve missed a bug or two somewhere along the line lets consider this another solid beta release.

So I need to update the .psd1 Module Metadata file for PowerBoots to include PoshWpf … I read up on Oisin Grehan’s blog about the possible properties in the module manifest, and decide that I could do this by packaging PoshWpf as a NestedModule in PowerBoots. There’s not a whole lot of point in distributing PoshWpf as it’s own module — Version 1 users will need to install it as a Snapin anyway, since PowerShell 1.0 doesn’t support modules, and I expect PowerShell 2.0 users to use it with PowerBoots.

Nested Modules

So I open up the PowerBoots.psd1 file, and add the line: NestedModules="PoshWpf" and fire up PowerShell and run Import-Module PowerBoots … and get this Error:
Import-Module : The module to process ‘PowerBoots’, listed in module manifest ‘C:\Users\Joel\Documents\WindowsPowerShell\Modules\PowerBoots\PowerBoots.psd1’ was not processed because no valid module was found in any module directory.

Now, I have no idea what that’s supposed to mean, except that I know the way that the PowerBoots.psm1 script gets parsed is that the PowerBoots.psd1 metadata includes a line: ModuleToProcess="PowerBoots.psm1" … I don’t know why the error doesn’t say “.psm1”, and I don’t know why that would be the error when what I added was the PoshWpf line, but I comment my line out and everything works, so I decide that maybe I need to say “PoshWpf.dll” (following the example that works of loading the PowerBoots script by specifying the full extension).

So I move PoshWpf.dll from it’s subdirectory right into the PowerBoots folder, and I change my line to: NestedModules="PoshWpf.dll" and fire up PowerShell and run Import-Module PowerBoots … and get this Error: Import-Module : An item with the same key has already been added.

Wow, I’m two for two: two attempts to load my module, two completely incomprehensible errors.

Required Modules

I noticed on Oisin’s site earlier that he mentioned something I didn’t know. There’s a RequiredModules property for module metadata, which I knew about, but although it will not try to load the module, Oisin’s post mentions that “this could optionally be done using a script in ScriptsToProcess” ... so I check that out.

I put PoshWpf.dll in it’s own Module folder: C:\Users\Joel\Documents\WindowsPowerShell\Modules\PoshWpf and I check that I can load it: Import-Module PoshWpf and then check that I can load PowerBoots: Import-Module PowerBoots. Success! Now to put in a script, with just that one line. I call it “PoshWpf.ps1” and put it the PowerBoots folder, and then add this line: ScriptsToProcess="PoshWpf.ps1" and … get another error Import-Module : The required module ‘PoshWpf’ is not loaded. Load the module or remove the module from ‘RequiredModules’ in the file ‘C:\Users\Joel\Documents\WindowsPowerShell\Modules\PowerBoots\PowerBoots.psd1’.

This time it’s obvious: despite what Oisin said, the script doesn’t run before the requirement is validated, so it doesn’t work the way I thought he meant. I switch the order of the lines around to see if it makes any difference, but it doesn’t. I decide that if I can just load the PoshWpf module, maybe I don’t care if it’s marked as “required” (it’s not technically required, you can still use Out-Boots — it’s just deprecated). So I comment out the requirement … and that works.

But that’s not nested

So at this point I’m almost ready to declare this a partial success and move on. But I’m an obsessive guy, and I don’t like the fact that people who don’t read this whole article won’t know how to get a list of all the PowerBoots modules (ie: they have to run Get-Command -Module PowerBoots, PoshWpf because the modules are completely separate, as far as PowerShell is concerned). So I really wanted to make it a nested module.

Somewhere around this point, I went to bed. When I woke up, I was having a conversation with someone on IRC that made me think of using @() notation…

So I went back to the beginning and try the line as: NestedModules=@("PoshWpf") but I still got the same error as before: Import-Module : The module to process ‘PowerBoots’, listed in module manifest ‘C:\Users\Joel\Documents\WindowsPowerShell\Modules\PowerBoots\PowerBoots.psd1’ was not processed because no valid module was found in any module directory. This time I got curious, so I ran it with -Debug and -Verbose on, and suddenly I was even more confused. The verbose output starts with the news that the loader is loading both PowerBoots.psd1 and PowerBoots.psm1, and then lists all of the functions created by PowerBoots.psm1 …

After a little digging, it’s clear that what they meant was that PoshWpf wasn’t being loaded … because PowerBoots itself is loaded fine. The error message is just completely wrong, and very frustrating. So now I’m thinking maybe I’m just not specifying the path to the nested module right…

I tried putting “.\PoshWpf” (since at this point I have PoshWpf in a subfolder of PowerBoots), and I got the old Import-Module : An item with the same key has already been added error again! Aarrgh

Losing patience

In frustration, I changed my profile to pre-set $VerbosePreference and $DebugPreference and $WarningPreference to “Continue” so that I could get as much information as possible (since I was having to restart PowerShell to be sure that the “item with the same key” error wasn’t fake). The next thing I tried was to set the full path to the dll: NestedModules="PoshWpf\PoshWpf.dll" and suddenly it seemed to work. The Verbose output included the exporint and importing of the cmdlets from PoshWpf … but I was still getting the “item with the same key” error at the end.

That made me kind-of curious, since the error appears to terminate loading, so to aid in debugging I commented out some code in my PowerBoots module, because that .psm1 file exports hundreds of functions, which makes it hard to tell exactly what’s happening… and discovered that the functions from PoshWpf.dll are being double-imported … so that’s probably what caused the duplicate key error. I try a few things, and finally resort to Set-PSDebug -Step …

Only to discover that when the PoshWpf.psd1 file says: ExportedCmdlets="Out-Wpf", the system seems to export and import all of the cmdlets… plus all the functions from the parent module that were already exported! I have no idea what’s going on, so I’m blogging, and contacting some MVPs, maybe they’ve seen more info than I have.

A solution!

After talking to a couple people, it’s pretty clear that what I’m doing should work, but doesn’t. I switch back to my earlier attempt: move PoshWpf.dll into the root PowerBoots directory, and set the NestedModules="PoshWpf" … of course I get the same error as before, but this time I’m running in full verbose, debug and trace mode, and I can see that all the cmdlets are actually being loaded, but the script functions are being hit oddly.

In a fit of confusion I try commenting out my ModuleToProcess="PowerBoots.psm1" line, and I put the script module into the nested modules list: NestedModules="PoshWpf","PowerBoots.psm1" … and suddenly it just works. I uncomment the function generation in PowerBoots.psm1, and it appears we’re good to go. I can’t decide if this is a bug, or just a problem of missing documentation. In any case, loading bot the psm1 and dll as nested modules works, and causes all of the functions and cmdlets to show up when I run Get-Command -Module PowerBoots, which is really the important part. Case closed — I’ll just have to write up something on connect to see what the Microsoft team says about fixing these error messages and documenting how on earth we’re supposed to use module metadata.

The problem was, half of the need we have for graphs is to throw them up on a web-server … so I needed a way to take the WPF window, and capture the controls and visuals as an image. Basically, render the WPF control to a bitmap image, instead of to the screen. To cut a long story short, I figured it out of course — why else would I be writing this? (get it here).

Out-BootsImage

So the new version of PowerBoots includes the Out-BootsImage function (aliased as BootsImage and “obi”), which basically is designed to take the filename of an image, and a boots visual element, and create a screenshot. It can generate bmp, gif, jpg, png, tiff, and even Microsoft’s new wdp format, or it can output to clipboard.

It’s late, so I’m not going to write any more about this … the bottom line is, if you have been looking for a (free) way to generate graphs and charts to image files in PowerShell, this will work for you: go grab Visifire, check out their gallery for inspiration, and start churning out graphs! Just for fun, here are the samples from the help documentation (except, this is the actual script I ran, including the upload code) with screen-shots …

Important note

When producing images of Visifire charts using this method, it is absolutely critical that you must specify -Animation $false because otherwise you will consistenly produce images of empty charts (since by default Visifire animates all of the bars onto the screen right after the SourceInitialized event that I use to capture the image). Oh, and if you need to remove the Visifire.com watermark, there is a -watermark $false parameter on the Chart element, which turns it off.