Exploring the Glide Path of PowerShell

Wed, Sep 27, 2006 2-minute read

As people begin to explore PowerShell, the question often comes up – “Will PowerShell support the cmdlet or language feature <foo>?”

For example (from the newsgroup,) “Is there a way to get the unmodified contents of a file – since Get-Content splits it into lines?”  Or from Occasionally Rabid Programmer, “… Is there a zipping PowerShell class yet?”  For many of these questions, the answer is, “Yes. Since PowerShell gives you access to all of the .Net Framework, you could also ask ‘Does the .Net Framework support <Foo> yet?'”

Clearly, PowerShell is evolving, and we have no plans to make you write everything yourself.

For many scenarios, though, people will often even solve their problem using classes from the .NET Framework, but worry that it isn’t “PowerShell-y” enough.

There is often a distinction, but usually there is not.  We designed PowerShell to allow you to smoothly glide between typical scripting tasks and more complex programming tasks – our support for .Net being a key to this spectacular amount of breadth.

For example, PowerShell will likely not ever support random I/O on a file stream through a cmdlet or language primitive.  That’s a task that the .NET Framework handles well, using a model that users are familiar with.  It doesn’t make much sense for PowerShell to re-implement all of that, just as there will always be sections of the Win32 API that .Net users need to call through P/Invoke techniques.

As you move away from goals obviously covered by language primitives and stock cmdlets, there comes a point where it just makes sense to leverage the powerful features of .NET interop.  Learning the breadth of the .NET Framework Library takes some patience, but is well worth it.  You can start by browsing and searching on http://msdn.microsoft.com/library/, and it is also a topic that my upcoming PowerShell Quick Reference deals with in some depth.