Media And Microcode : Select-Object

Microcode: A Quick Trick to turn regular XML into Xaml

JamesBrundage — Thu, 22 Jan 2009 13:07:36 GMT

MSDN has tons of examples about XAML. Nearly everything in WPF has an example in XAML, but not all of these XAML examples actually reference the namespace that is required for this Xaml to be loadable by WPF. It's still valid XML, just not valid XAML.

Here's a quick example of what I mean. I just copied and pasted this chunk from the MSDN topic on LinearGradientBrush:

<Rectangle Width="200" Height="100">
<Rectangle.Fill>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
      <GradientStop Color="Yellow" Offset="0.0" />
      <GradientStop Color="Red" Offset="0.25" />
      <GradientStop Color="Blue" Offset="0.75" />
      <GradientStop Color="LimeGreen" Offset="1.0" />
    </LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>

Now if I try to simply load that up as XAML, XamlReader barfs

$x =[xml]'
<Rectangle Width="200" Height="100">
<Rectangle.Fill>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,1">
      <GradientStop Color="Yellow" Offset="0.0" />
      <GradientStop Color="Red" Offset="0.25" />
      <GradientStop Color="Blue" Offset="0.75" />
      <GradientStop Color="LimeGreen" Offset="1.0" />
    </LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
'
[Windows.Markup.XamlReader]::Parse($x.OuterXml)

Exception calling "Parse" with "1" argument(s): "'' XML namespace prefix does not map to a namespace URI, so cannot resolve property 'Width'. Line '1' Position '79'."
At line:14 char:35
+ [Windows.Markup.XamlReader]::Parse <<<< ($x.OuterXml)
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException

Obviously, that's not ideal. Luckily, with CTP3, there's a cmdlet called Select-Xml, which will allow me to query a document with xPath, regardless of namespaces.

This means that I can check to see if the fist element has a reference to the WPF namespace, and add it if it's not there.

$t = $x |
    Select-Xml //* |
    Select-Object -First 1 |
    Foreach-Object {
        if (-not $_.Node.xmlns) {
            $_.Node.SetAttribute("xmlns", 'http://schemas.microsoft.com/winfx/2006/xaml/presentation')
        }
        $_.Node.OuterXml
    }

I'll stop and explain this pipeline a little. $x is the XML, I pipe it into Select-Xml, with the xPath parameter of //*. //* roughly translates to any node. I pick out the first node (with Select-Object -first 1) and then I check to see if the Node contains an xmlns attribute. If it doesn't, I add it. Either way, I emit the first node's OuterXml, which basically means I emit the entire XML chunk as text. That's what $t is when I am done.

Then I use this chunk to display it:

$w = New-Object Windows.Window
$w.Content = [Windows.Markup.XamlReader]::Parse($t)
$w.SizeToContent = "WidthAndHeight"
$w.ShowDialog()

Now I have the MSDN sample working, regardless of if it had an xmlns attribute in the first place.

Hope this Helps,

James Brundage [MSFT]

Microcode: PowerShell Scripting Tricks: Select-Object (Note Properties) vs Add-Member (Script Properties)

JamesBrundage — Wed, 26 Nov 2008 07:30:20 GMT

As I've said a number of times before, PowerShell's quantum leap forward is something called the Object Pipeline. It allows you to take the results of one command and easily use them with the next, which means that each command you create becomes a link in a chain rather than an isolated island.

In several posts, I've talked about how to create objects that are property bags as a means to an end (such as when I was Cleaning Up Get-RecordedTV with Select-Object), but I haven't really focused on how to make property bags that much on its own.

There are two basic ways you can create property bags in PowerShell. The first is by using the Add-Member cmdlet, and the second is by using Select-Object. As with anything in programming, deciding which way to get a task done involves some trade offs. Most of the trade off between Select-Object and Add-Member has to do with what type of properties the commands add to objects. Select-Object will add note properties, which are fine for most purposes and quick to create, but they cannot do anything when the properties are set and cannot create properties that are always up to date.

The following table shows when I tend to use Select-Object versus Add-Member

When your priority is...	You should use...
Adding a few quick properties to an existing object	Select-Object
Adding properties that may be take time to evaluate or need to be up-to-date	Add-Member
Creating a property bag to summarize information from cmdlets	Select-Object
Wrapping an existing object with a friendlier surface area	Add-Member
Adding a single property to an object	Add-Member

The bottom line of choosing which way to make your property bag comes down to speed and convenience. Because you have to call Add-Member once for every property you wish to add to an object, Add-Member is often slower to use for this purpose than Select-Object. However, to be fair, Select-Object is kind of ugly and a little inconvenient to write. To prove the speed gain and illustrate the strange syntax of Select-Object, here's two equivalent scripts that both create an object with two properties, Foo and Bar:

Select-Object	Add-Member
1 \| Select-Object @{ Name='Foo' Expression={"Bar"} }, @{ Name='Bar' Expression={"Baz"} }	New-Object Object \| Add-Member NoteProperty Foo Bar -passThru \| Add-Member NoteProperty Bar Baz -passThru

Obviously, Select-Object is a lot less clean looking than Add-Member. To determine which is faster, just pack each item into a long loop and run Measure-Command.

Measure-Command {
    foreach ($n in (1..1000))  {
        1 | Select-Object @{
            Name='Foo'
            Expression={"Bar"}
        }, @{
            Name='Bar'
            Expression={"Baz"}
        }
    }
}

Measure-Command {
    foreach ($n in (1..1000))  {
        New-Object Object |
            Add-Member NoteProperty Foo Bar -passThru | 
            Add-Member NoteProperty Bar Baz -passThru
    }
}

On my computer, Select-Object is much faster. It's actually twice as fast over 1000 objects. The more properties you add with Add-Member, the slower it will be. This concern should really only come into play when dealing with thousands of objects, so if you were adding properties to the output of Get-Process, the difference should be negligible, but if you're adding properties to every single file underneath Windows\System32, you'll probably want to use Select-Object.

Add-Member does have one huge advantage over Select-Object, and that's the type of properties that it can tack on. Select-Object adds Note Properties, which means that it will evaluate each item as you add it to the object (and never again). For instance, if I wanted to add a property to a file object that would tell me who currently had the file open, then I would need that property to always be up to date. In this case, if you had a command that would determine if the file was open (let's call it Test-FileOpen) you could add something like Add-Member ScriptProperty IsOpened { Test-FileOpen $this.Fullname }.

The other thing you can do with a script property that you can't do with a note property is set values. To do this with a ScriptPropery, you simply give Add-Member two script blocks. The first is a getter and the second is a setter. In the simple example below, I update the value of Bar through the setter of Foo

$i = New-Object Object |
    Add-Member NoteProperty Bar "baz" -passThru |     
    Add-Member ScriptProperty Foo {$this.Bar} { $this.Bar = $args[0]} -passThru 
$i
$i.Foo = "bing"
$i

ScriptProperties are especially useful if you would like to take a surface area that's awkward and make it nicer to use in PowerShell. In this case, you simply create a new object, attach the original object to it as a note property, and then use Script Properties to talk to the original object. Sadly, in order to demonstrate the usefulness of that particular capability, I have to walk through a long and complicated API. Rather than make this post more long and complicated, I'll leave this post as food for thought on where you can use note properties and script properties in your code.

Have fun experimenting, and remember: Select-Object's Speedy, Add-Member's Adaptable.

Hope this helps,

James Brundage [MSFT]

Microcode: Scripting RSS Feeds with PowerShell and Microsoft.FeedsManager

JamesBrundage — Tue, 11 Nov 2008 04:34:53 GMT

PowerShell's an amazing glue language. It can help you bring code from all corners of the earth into one environment, and then you can custom the code to be more to your liking. While the last several entries of my blog have spent time looking at what we can glue together with .NET, this one shows you how you can bring COM into the mix.

Internet Explorer has an RSS feed manager which you can script in .NET. While the command line might not be the ideal spot to read your blogs, it's possible to make a much nicer front end by scripting WPF & PowerShell, and having a quick and easy API to get at your RSS feeds makes building applications that use RSS feeds as a way to synchronize information between multiple machines.

The object that makes this all work is Microsoft.FeedsManager, and the cmdlet that makes working with it possible is New-Object. By default, New-Object will create a new .NET object from the classes that are currently loaded by .NET (for more on this, see my previous posts about Get-Type and Get-Assembly). While .NET is a fairly easy world to explore, COM is considerably more tricky.

Luckily, COM objects are the main backbone of VBScript. This is an important point for VBScripters trying to learn PowerShell: while the world of .NET may be new and exotic, and Cmdlets might be cool, you don't have to drop your VBScript knowledge at the door. While some of a VBScript (e.g. strings) will require new learning in PowerShell, the vast majority of it doesn't.

Microsoft.FeedsManager is one of these examples. I found out about this object by looking at the source code for the RSS reader vista sidebar gadget, and, once I knew its name, I knew how to get at it in PowerShell. Even though I was looking at javascript, I knew that there was a scriptable COM object there to help me out, and I knew how to bring it into PowerShell.

To create a Microsoft.FeedsMananger, simply use this one liner:

New-Object -comObject Microsoft.FeedsManager

Since the root folder looks promising, let's explore that:

(New-Object -comObject Microsoft.FeedsManager).RootFolder

While I can just save this into a variable and script it like I were still in VBScript land (e.g. $feeds = New-Object -comObject Microsoft.FeedsManager, $feeds.RootFolder), I far prefer the parlance of PowerShell, so I'll make a quick Get-Feed function to explore feeds more easily. I'll accept a wildcard for the name or title of the feed, and, since the feeds can have an arbitrary number of subfolders, I'll add a -recurse parameter. In order to make -recurse work elegantly, I'll use a short recursive script and I'll add a $folder parameter, which can be null and will be assumed to be the root folder. Finally, since I'll often want to read the items more than the feed, I'll add a switch parameter to extract the articles.

function Get-Feed($feed = "*", $folder, [switch]$recurse, [switch]$articles) {
    if (! $folder) {
        $feedsManager = New-Object -ComObject Microsoft.FeedsManager
        $folder = $feedsManager.RootFolder
    }
    $folder.Feeds |
        Where-Object {
            ($_.Title -like "$feed") -or ($_.Name -like "$feed")
        } | Foreach-Object {
            if ($articles) { $_.Items } else { $_ }
        }
    if ($recurse) {
        $folder.Subfolders | Foreach-Object {
            Get-Feed $feed $_ -recurse -articles:$articles
        }
    }
}

Once I've defined Get-Feed, I can use it to search my feeds through PowerShell. This one liner will get my all my feeds, sort them by name, and display just the Name and URL:

Get-Feed -recurse | Sort-Object Name | Select-Object Name, URL

To see all of the feed items sort them by when they were published, and display the post title, the blog title, and the publish date, you can use this pipeline:

Get-Feed -articles -recurse |
Sort-Object PubDate -descending |
Select-Object Title, @{Name='Blog'; Expression={$_.Parent.Title }}, PubDate

I promise that we can do much more with RSS and PowerShell, but hopefully this post will get you started down the path of using the FeedsManager from PowerShell.

Hope this helps,

James Brundage [MSFT]

Module Name	Scripts
RSS	Get-Feed

Microcode: PowerShell Scripting Tricks - Exploring .NET Types with a Get-Type function and Reflection

JamesBrundage — Fri, 24 Oct 2008 01:16:02 GMT

There's a simple yet powerful function that nearly everyone on the PowerShell team has written a version of. My version is called Get-Type. It's only a one-liner, but it's an amazing way to explore .NET and it's also an amazing example of some of the things you can do with the object pipeline. What my version does is get all of the existing .NET types loaded in the current program. In this post, I'll introduce the basic function, and I'll build upon it in order to show some cool things you can do with .NET reflection. I first introduced this function in the 2nd post of my series on WPF, but I didn't really show that much .NET fun with it.

Here's a simple version:

function Get-Type() {
[AppDomain]::CurrentDomain.GetAssemblies() | Foreach-Object { $_.GetTypes() }
}

Go ahead and run it. Running it on CTP2 of Graphical PowerShell on my home box, I got 19303 .NET types. That's over 19000 things you can build upon. 19000 potential solutions sitting right there at your fingertips. A remarkable amount of information can be gleaned just looking directly at the types, and it's a lot faster than looking it up on MSDN (although MSDN is a great companion to this knowledge).

How I figured out there were 19303 .NET types is a great example of the object pipeline:

Get-Type | Measure-Object

But that's only scratching the surface of what we can do with the rich data of .NET and PowerShell's powerful object pipeline.

Let's suppose that I want to find every Xml-related type:

Get-Type | ? { $_.Name -like "*Xml*" }

Now suppose I want to find the constructors of the constructors of the objects:

Get-Type | ? { $_.Name -like "*Xml*" } | % { $_.GetConstructors() } | % { "$_" }

Now suppose I want to check out what each constructor can do:

Get-Type | ? { $_.Name -like "*Xml*" } | % { $_.GetConstructors() } | Get-Member

Looking at this, I can see that constructors contain a GetParameters() method. Let's put that together with Get-Type to build something that will find all of the types that I can build using that type.

function Search-Constructor([Type]$parameterType, $namespace) {
    Get-Type |
    Where-Object { $_.Namespace -like "*$namespace*" } |
    Where-Object {
        $_.GetConstructors() |
        Foreach-Object {
            $_.GetParameters() |
                Where-Object {
                    $_.ParameterType -eq $parameterType
                }
        }
    }
}

It will probably take a little bit to run (on my machine, it took about 30 seconds to find anything that used XmlDocument in its constructor, with no namespace specified) , but you can easily use this to start discovering how .NET types interact.

Similar functions will let you find Properties, Events, and Methods:

function Search-Method([Type]$parameterType, $namespace) {
    Get-Type |
    Where-Object { $_.Namespace -like "*$namespace*" } |
    Where-Object {
        $_.GetMethods() |
        Foreach-Object {
            $_.GetParameters() |
                Where-Object {
                    $_.ParameterType -eq $parameterType
                }
        }
    }
}

If you want to check out any property, just use Select-Object to view the type. (You can also summarize the object by adding hashtables, for instance, this expression will output each type's fullname and all of their methods:

Get-Type | Select-Object FullName, @{Name='Methods';Expression={$_.GetMethods() | % {$_.ToString()}}}

This is a great example of the usefulness of the Object pipeline. Instead of getting a list of all of the typenames, you can delve deep into the what a type can do for you. The more you explore .NET. These little snippets should help get you started, but the sky's the limit. Try writing a few of your own. The more you explore .NET, the more you'll be amazed at the variety of code that exists to solve your everyday programming problems.

Hope this helps,

James Brundage [MSFT]

Microcode: Cleaning up Get-RecordedTV with Select-Object

JamesBrundage — Mon, 21 Jul 2008 02:28:15 GMT

In a previous post, I introduced Get-RecordedTV, which was built upon another function, Search-WindowsDesktop.

The old version of Get-RecordedTV directly returned the properties related to DVR from Windows Desktop Search, with incredibly long names like 'System.RecordedTV.IsRepeatBroadcast'. In the interests of making future code shorter and explaining one of the free benefits you get with objects in PowerShell (Select-Object), I'm going to start by giving a new Get-RecordedTV. Instead of giving you the properties directly from Desktop Search, this Get-RecordedTV reinterprets the results to make them easier to read.

function Get-RecordedTV() {
    Search-WindowsDesktop 'System.Title',
      'System.RecordedTV.EpisodeName',
      'System.RecordedTV.ChannelNumber',
      'System.RecordedTV.StationName',
      'System.RecordedTV.IsRepeatBroadcast',
      'System.RecordedTV.StationCallsign',
      'System.RecordedTV.ProgramDescription',
      'System.RecordedTV.IsSAP',
      'System.RecordedTV.IsHDContent',
      'System.RecordedTV.RecordingTime',
      'System.Video.FrameHeight',
      'System.Video.FrameWidth',
      'System.Video.EncodingBitrate',
      'System.Media.DateEncoded',
      'System.ParentalRating',
      'System.Size',
      'System.ItemPathDisplay' "WHERE System.RecordedTV.ChannelNumber IS NOT NULL" |
    Select-Object @{Name='Series';Expression={$_.'System.Title'}},
      @{Name='Episode';Expression={$_.'System.RecordedTV.EpisodeName'}},
      @{Name='Description';Expression={$_.'System.RecordedTV.ProgramDescription'}},
      @{Name='Channel';Expression={
          "$($_.'System.RecordedTV.ChannelNumber')-$($_.'System.RecordedTV.StationCallsign')-$($_.'System.RecordedTV.StationName')"
      }},
      @{Name='File';Expression={
          Get-Item $_.'System.ItemPathDisplay' -errorAction SilentlyContinue
      }},
      @{Name='Size';Expression={$_.'System.Size'}},
      @{Name='DateRecorded';Expression={$_.'System.RecordedTV.RecordingTime'}},
      @{Name='IsSAP';Expression={$_.'System.RecordedTV.IsSAP'}},
      @{Name='IsHD';Expression={$_.'System.RecordedTV.IsHDContent'}},
      @{Name='IsRepeatBroadcast';Expression={$_.'System.RecordedTV.IsRepeatBroadcast'}},
      @{Name='Width';Expression={$_.'System.Video.FrameWidth'}},
      @{Name='Height';Expression={$_.'System.Video.FrameHeight'}},
      @{Name='Rating';Expression={$_.'System.ParentalRating'}}
}

This entire function is still one pipeline. It gets the results from Search-WindowsDesktop, and, as each item arrives, it pipes the results to Select-Object.

Select-Object is an incredibly useful PowerShell Cmdlet. It is used to select one or more objects from a type, and return them in a bag of properties. While it works great for selecting just a property or two (e.g. Get-Process | Select Name, ID), it can also be used in some interesting other ways.

The way I use it above is to rename a number of properties. If you have an parameter in Select-Object that takes the format @{Name='String';Expression={expression}}, you will create a new property on the object with the value of the expression. You can refer to something on the current object by using $_ (which, in PowerShell, is pretty commonly the current element in the pipeline). You can also use this to run methods and return their values as properties. And, finally, you can actually create a type that is only properties this way, by using a simple other PowerShell coolness, the range operator.

So, to create one hundred anonymous objects with two random numbers:

$random=New-Object Random
1..100 |
Select-Object @{Name='Random1';Expression={$random.Next()}},
@{Name='Random2';Expression={$random.Next()}}

People familiar with functional programming might know this sort of thing as a Tuple, but knowing the correct terminology doesn't help the usefulness sink in all that much to me.

In the case of Get-RecordedTV, the first use is pretty obvious: it reduces the amount of typing for each property name and makes it easier to identify. The second advantage is more subtle. By re-interpreting the return type from Search-WindowsDesktop to be a bunch of properties that the system decides to a bunch of properties that I choose, it means that I can make the dependency on Search-WindowsDesktop removable. In doing so, I hurt anyone that has already built scripts around Get-RecordedTV, because they have to change their scripts to handle a new signature for the anonymous type, because the change subtracted types.

Subtractive changes break backwards compatibility, but in this case it frees me from the stack that I used to depend on. This is a wonderful flexibility of writing in an interpreted language, and can be valuable because you can use it to make a flexible dependency instead of a fixed one. With a flexible dependency, if I find out that they have turned Windows Desktop Search off, or I find a better mechanism down the line, I can replace my dependency on Search-WindowsDesktop with another technology.

I could write an interface to express the data I want to get, but that's overkill for my situation. If I write an interface, then I have to have a real type already loaded, and I've swapped one dependency (on Search-WindowsDesktop) for two ( the type that implements the interface and the interface type ) and have essential hard-bolted a dependency on my interface to any application that wants to use the data.

Anonymous types allow you to get most of the benefits of interfaces with a flexible dependency. As long as you keep the bag of properties the same, you can build upon scripts that return anonymous properties. You can use this to coerce data into forms that are easier to remember, and to summarize data in simpler forms. You will also find that a number of cmdlets within PowerShell (Select-Object, Sort-Object, and Group-Object) work amazingly well with bags of properties.

In a later posts, we'll use this base of code and these cmdlets to prune the collection, and demonstrate how the use of property bags and the exploration into Windows Desktop Search leads to a variety of wonderful side effects.

Hope this Helps,

James Brundage [MSFT]