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: 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]

Media And Microcode : Get-Type

Microcode: Exploring More of .NET with Get-Assembly

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