Gallery

Shell power for Windows

Posted on 29 Jun 2006 at 11:22

Thomas Lee looks at microsoft's cool new administration shell and scripting tool, powershell, and finds out how it fits into the .NET framework

If this all sounds simple, it is, but it's taken Microsoft several years to get this far. A key aspect of the design of PowerShell is the transfer and leverage of knowledge; that is, knowing one cmdlet helps you to understand what another does. Most PowerShell cmdlets are just simple extensions of the base .NET classes, but with carefully chosen names.

Raw .NET access

At the other end of the scale from using PowerShell cmdlets, you can reach directly into the .NET class libraries and use raw .NET Objects, methods and properties. In the screenshot above, you'll see a call to the GetProcesses( ) method on the System.Diagnostics.Process class. You'll quickly discover that if you take a C# or VB.NET program, you can translate its code pretty well directly into a PowerShell script. The GET-MEMBER cmdlet will return all the details of the objects returned by other cmdlets, or by raw .NET methods.

Using such raw access delivers two main benefits. First, it removes the headroom restrictions typical of so many tools. If you can do it in .NET, you can do it in PowerShell and without the myriad of extra tools the Unix guys need (awk, grep, perl and so on). Second, it makes it easy to expand and build on the .NET Framework: you can write your own cmdlets either in C# code or using PowerShell itself. Here's a simple function that uses the SYSTEM.NET.DNS classes RESOLVE method to resolve a host name:

function resolve-dns

{

Param ($hostname=$(throw "ERROR: Please supply a host name"))

return [system.net.dns]::resolve($hostname)

}

When you use this function, effectively a cmdlet written script, it returns an IPHOST entry for the given host (or an error), as shown here:

PSH [C:\]: $i = resolve-dns www.microsoft.com

PSH [C:\]: $I | gm

TypeName: System.Net.IPHostEntry

Name MemberType Definition

---- ---------- ----------

Equals Method System.Boolean Equals(Object obj)

get_AddressList Method System.Net.IPAddress[] get_AddressList()

get_Aliases Method System.String[] get_Aliases()

get_HostName Method System.String get_HostName()

GetHashCode Method System.Int32 GetHashCode()

GetType Method System.Type GetType()

set_AddressList Method System.Void set_AddressList(IPAddress[] value)

set_Aliases Method System.Void set_Aliases(String[] value)

set_HostName Method System.Void set_HostName(String value)

ToString Method System.String ToString()

AddressList Property System.Net.IPAddress[] AddressList {get;set;}

Aliases Property System.String[] Aliases {get;set;}

HostName Property System.String HostName {get;set;}

PSH [C:\]: $I |FT *auto

PSH [C:\]: $I |Fl

HostName : lb1.www.ms.akadns.net

Aliases : {www.microsoft.com, toggle.www.ms.akadns.net, g.www.ms.akadns.net}

AddressList : {207.46.198.60, 207.46.20.30, 207.46.225.60, 207.46.199.30...}

Thus, you wrap complex functionality into simple and easier- to-use functions or cmdlets. The Exchange 2007 team is taking the approach of creating huge numbers of custom cmdlets that enable you to manage an Exchange server totally from the PowerShell command line.

Enhanced .NET access

PowerShell permits raw .NET access, but also provides considerable power on top of it. For example, PowerShell adds support for the complex object types you most commonly use in scripting - such as [XML] or [Array] - as well as the simple types like [int] or [string]. Thus, when creating a variable in PowerShell, you can be strict as to what is allowed: