Microcode: Exploring More of .NET with Get-Assembly

JamesBrundage — Sat, 08 Nov 2008 03:46:03 GMT

In a previous post, I introduced a function called Get-Type, which allows you to see all of the types currently loaded by .NET. What it doesn't do is help you find assemblies, the DLL files containing new types. So while there might be 19000-odd types loaded when I launch the Windows PowerShell Integrated Script Editor (aka Graphical PowerShell), it's the tip of the iceberg for what .NET can do.

Since the Iceberg is so huge, you probably do not want to try to load every bit of the iceberg just to see what it contains. So you're left with a classic Schrödinger's Cat problem (observing something may change what you observe).

Luckily, assemblies are located in a common spot on the filesystem, so it's actually really easy to find all of the assemblies that exist for public consumption without loading them. This will catch assemblies installed for public use, but it will not catch an assembly that lives in the same directory as a program.

In this post, I'll show you how to write a Get-Assembly function, and use it with the Object Pipeline to explore and load up specific assemblies. Since Assemblies exist underneath the Windows Directory, I can search the directory with Get-ChildItem (or dir, if you prefer).

Get-ChildItem (Join-Path $env:Windir "Assembly") -recurse -filter "*.dll"

If you run this, you should notice two things. First, there's a lot of output that goes by far too quickly to be useful to a person. Second, there's a bunch of files DLLs, and some files named something like Assembly.Ni.Dll. We cannot load those assemblies, so we'll remove them from the list by adding on a Where-Object. Then, to make loading up the assembly easier, I'll pipe each result to Add-Member in order to add a method to load the assembly.

function Get-Assembly()
{
    Get-ChildItem (Join-Path $env:Windir "Assembly") -recurse -filter "*.dll" |
        Where-Object {
            ! $_.Name.Substring(0,$_.Name.IndexOf($_.Extension)).EndsWith(".ni")
        } | Add-Member ScriptMethod Load -passThru {
            [Reflection.Assembly]::LoadFrom($this.FullName)
        }
}

This Get-Assembly gets rid of the DLLs we can't use, but it's still not ideal for human consumption because of how files are displayed. Files from different directories show up with a header for that directory, so running this produces a lot of white space when you're really interested in the name or the full path. Luckily, I can always summarize the object with Select-Object. The next bit will sort all of the assemblies by their name and output just that property.

Get-Assembly |
Sort-Object Name |
Select-Object Name

I can also use the Get-Assembly command to load up assemblies to explore with Get-Type. This next statement will walk through all of the assemblies related to Linq and load them up:

Get-Assembly |
Where-Object { $_.Name -like "*Linq*" } |
Foreach-Object { $_.Load() }

I can also save the loaded assemblies into a variable so I can use them later. For instance, I'll save the Linq assemblies and then use Get-Type to look through each of the types in those assemblies.

$assemblies = Get-Assembly |
    Where-Object { $_.Name -like "*Linq*" } |
    Foreach-Object { $_.Load() }

Get-Type | Where-Object {
    $type = $_
    $assemblies | Where-Object { $type.Assembly -eq $_ }
}

Get-Type and Get-Assembly work well together as a way to explore all that .NET has to offer. On my box, there's over 500 assemblies, of which only 41 are currently loaded in PowerShell. If 41 assemblies contain about 20000 types, imagine just how many pre-canned solutions exist in .NET just waiting for you to use.

Hope this Helps,

James Brundage [MSFT]

Download scripts:

Module Name	Scripts
DotNet	Get-Assembly
	Get-Type

Microcode: Scripting Tricks : Exploring WPF Routed Events with PowerShell

JamesBrundage — Mon, 20 Oct 2008 03:12:00 GMT

Both WPF and PowerShell are both full of great little touches. One of WPF's nice touches is Routed Events. Routed Events allow you to capture events raised by child controls or parent controls. This can be incredibly useful, because it allows you write less code (which I believe is generally good) by re-using handlers.

A good example of why you might want to do this is wanting to have more than one button in a user interface that updates a database. What each button might do may be different, but they all to connect to a database. This means you could write either write three longer (and less portable) methods that connect to the database and perform an operation, or three shorter ( and more portable ) methods that just perform the operation on a database and one operation that connects to the database. By having each of the buttons go through a routed event on a container, you can write one short routing handler that connects to the database, looks at where the message came from, and performs the operation.

WPF comes with an amazing number of controls, and a pretty nice selection of Routed Events. The WPF team was event nice enough to have a manager for these routed events, which means that we can explore them dynamically using PowerShell.

The event manager is available in the class System.Windows.EventManager. Let's start exploring it with PowerShell. To do this, make sure you've loaded the WPF assembly into PowerShell by using the line [Reflection.Assembly]::LoadWithPartialName("PresentationCore"). We can omit the System namespace when referring to a type in PowerShell, so we can call it [Windows.EventManager] from now on. We can use Get-Member -static to see what this class can do.

[Windows.EventManager] | Get-Member -static

It has the following methods:

Equals (every .NET object has this static member)
GetRoutedEvents()
GetRoutedEventsForOwner(Type ownerType)
ReferenceEquals (every .NET object has this static member)
RegisterClassHandler (Type classType, RoutedEvent routedEvent, Delegate handler)
RegisterClassHandler (Type classType, RoutedEvent routedEvent, Delegate handler, Boolean handledEventsToo)
RegisterRoutedEvent(String name, RoutingStrategy routingStrategy, Type handlerType, Type ownerType)

Since I'm just exploring, GetRoutedEvents() is the method I'm interested in.

I can see every routed event with the simple PowerShell one-liner:

[Windows.EventManager]::GetRoutedEvents()

Of course we can pipe that to Get-Member in order to see what we've got for every Routed Event:

[Windows.EventManager]::GetRoutedEvents() | Get-Member

It's more interesting to me to figure out what events I can bubble up to the parent controls. Since each RoutedEvent has a RoutingStrategy property, I can write this as a simple filter using Where-Object:

[Windows.EventManager]::GetRoutedEvents() | Where-Object { $_.RoutingStrategy -eq "Bubble"} | Sort-Object Name

Since each RoutedEvent also has a HandlerType property, I can also see what types of different handlers exist by using

[Windows.EventManager]::GetRoutedEvents() | Group-Object HandlerType | Sort-Object Count -descending

Finally, I can use the EventManager to help guess about what types of controls could fit the bill for whatever I need to do. The next one liner gives me all of the routed events that work with Drag and Drop

[Windows.EventManager]::GetRoutedEvents() | Where-Object {$_.Name -like "*Drag*" -or $_.Name -like "*Drop*" }

Associating these events with a class needs to use some tricks of reflection. In the sample below, I'll look for all drag and drop handlers within PresentationBase (where the EventManager and some base components live) and PresentationFramework (where most of the built-in WPF controls reside):

$handlers = [Windows.EventManager]::GetRoutedEvents() |
    Where-Object {
        $_.Name -like "*Drag*" -or $_.Name -like "*Drop*"
    }
$assemblies = [Windows.EventManager].Assembly,
    [Windows.Window].Assembly

$assemblies | Foreach-Object {
    $_.GetTypes() | Where-Object {
        foreach ($handler in $handlers) {
            if ($_.GetEvent($handler.Name)) {
                return $true
            }
        }
    }
}

The script above takes a bit of explaining.

I store the Drag and Drop handlers into a variable, and store the assemblies I wanted to search in another variable (to search all of my currently loaded types for these handlers, I'd use just assign $assemblies to [AppDomain]::CurrentDomain.GetAssemblies()). Then I go through each assembly, retrieve the types, and pipe them into Where-Object, which will determine if they meet my criteria. I go through each class and each handler that met my criteria, and use the GetEvent method (which is defined on any .NET type definition) to determine if the event is present. If the event is present, I return $true, which makes the Where-Object output the type. If the event's not present, then code will go onto the next handler and the next type.

These are just a few examples of the ways you can use PowerShell to explore WPF routed events. The techniques used in this post can be used on to explore just about any .NET type. Exploring .NET through reflection is a great way to save time looking things up, and the pathway to using existing .NET code to solve a problem rather than reinventing the wheel.

Hope this helps,

James Brundage [MSFT]

Media And Microcode : .NET

Microcode: Exploring More of .NET with Get-Assembly

Microcode: Scripting Tricks : Exploring WPF Routed Events with PowerShell