Using PowerShell Get-Member to Explore the .NET Framework

Summary: Learn how to use the Windows PowerShell Get-Member cmdlet to explore the .NET Framework in this interactive how-to post.

Hey, Scripting Guy! When you give examples of using the Get-Member cmdlet to explore the members of something in Windows PowerShell it seems so easy. The problem is that when I use it, things do not seem so easy. Sometimes it works, and other times it provides totally bogus information. Can you help me discover what I am doing wrong?

— PN

Hello PN, Microsoft Scripting Guy Ed Wilson here. It is early in the morning, and there is fog hanging close to the ground. Last night the wind howled, the leaves rustled, and the rain came down like a heavy mist for most of the night. At times, the moon was peeking from behind the high clouds. It was a cool night, figuratively and literally. I am sipping on a cup of English Breakfast tea with a cinnamon stick in it, and munching on a freshly baked slice of pumpkin bread. I have my Zune HD cranked up and it is blasting some classic James Brown. It is a retro morning as I weed my way through some of the questions sent to Scripter@Microsoft.Com.

Speaking of retro classics, PN your question reminds me of the things that bugged me when I was just learning Windows PowerShell, and that is the seemingly inconsistent behavior of the Get-Member Windows PowerShell cmdlet. If I assign an integer to a variable, and then pipeline that variable to the Get-Member cmdlet it correctly detects the item as an instance of the System.Int32 .NET Framework class (int32 is the class, System is the namespace) and displays the members (methods, properties, events). The Int32 class does not expose any properties or events. (One thing that this shows is that by default Windows PowerShell treats an integer as an int32). This is seen here.

All this information is well and good, but I thought I had an array. Where is that information? There are, as you may know, two ways of using the Get-Member cmdlet. The first way, the way I use it most frequently, involves piping an object to the cmdlet. The second way is to pass the object to the inputobject parameter. This technique is illustrated here with the associated output.

PS C:\> $array = 1,2,3,4

PS C:\> Get-Member -InputObject $array

TypeName: System.Object[]

Name MemberType Definition

—- ———- ———-

Count AliasProperty Count = Length

Address Method System.Object&, mscorlib, Version=2.0.0.0, Culture=n…

Clone Method System.Object Clone()

CopyTo Method System.Void CopyTo(array array, int index), System.V…

Equals Method bool Equals(System.Object obj)

Get Method System.Object Get(int )

GetEnumerator Method System.Collections.IEnumerator GetEnumerator()

GetHashCode Method int GetHashCode()

GetLength Method int GetLength(int dimension)

GetLongLength Method long GetLongLength(int dimension)

GetLowerBound Method int GetLowerBound(int dimension)

GetType Method type GetType()

GetUpperBound Method int GetUpperBound(int dimension)

GetValue Method System.Object GetValue(Params int[] indices), System…

Initialize Method System.Void Initialize()

Set Method System.Void Set(int , System.Object )

SetValue Method System.Void SetValue(System.Object value, int index)…

ToString Method string ToString()

IsFixedSize Property System.Boolean IsFixedSize {get;}

IsReadOnly Property System.Boolean IsReadOnly {get;}

IsSynchronized Property System.Boolean IsSynchronized {get;}

Length Property System.Int32 Length {get;}

LongLength Property System.Int64 LongLength {get;}

Rank Property System.Int32 Rank {get;}

SyncRoot Property System.Object SyncRoot {get;}

PS C:\>

At first brush, it seems that the command has not worked as intended. After all, it says that it is a System.Object[]. But the square brackets tell me that I have an array, and if I compare the results with the members detailed for the System.Array .NET Framework class on MSDN shown in the following figure, it shows that I am in fact, working with an instance of a System.Array.

All the properties are surfaced through the Get-Member cmdlet. One thing that seems to be amiss is that the methods seem to be missing. The key to understanding the results that I have obtained is in realizing that I am working with an instance of the System.Array class. Instance members (properties and methods) are available as soon as an instance of the class has been created. Static members are available without having to create an instance of the class. As discussed yesterday, static members in MSDN are indicated with a big red “S”.

The static members of the System.Array .NET Framework class are seen here.

The methods on MSDN that are not marked with a big red “S” are shown largely in the display of the System.Object[] output.

PN, that is all there is to using Get-Member to discover hidden members. I encourage you to play around with the output, and compare results with the class descriptions on MSDN. .NET Framework week will continue tomorrow when I will talk about additional ways to explore classes using the Get-Member cmdlet.