Windows PowerShell for Developers

Chapter 1. Introduction

There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions and lukewarm defenders in those who may do well under the new.

—Nicolo Machiavelli, The Prince

PowerShell is the next-generation platform for distributed automation in the Microsoft Windows environment. It provides significant benefits to developers, testers, power users, and administrators. PowerShell works by leveraging the .NET Framework, and provides significant benefits to developers, testers, power users, and administrators. PowerShell leverages .NET to provide a powerful, consistent, intuitive, extensible, and useful set of tools that drive down costs, and make it easier to program for and automate Windows.

PowerShell was developed in 2002 under the code name Monad. In 2006, Microsoft published Release Candidate 1 of the platform, simultaneously announcing its new name, Windows PowerShell. Today PowerShell v3 is being delivered with Windows 8 and Windows Server 2012 and is available for Windows 7.

Note

For a slightly reworked version of inventor Jeffrey Snover’s opening to the Monad Manifesto whitepaper, which outlined the core ideas behind what would eventually become PowerShell, see http://bit.ly/n68k1X.

New PowerShell developers can often create timesaving scripts after just a few hours of learning. There are numerous accounts of people seeing huge reductions in time spent solving problems using PowerShell, compared to traditional system programming languages.

Another distinguishing feature of PowerShell is the fact that you can embed it into .NET applications. Adding the PowerShell scripting engine to a Windows .NET application allows you to provide a full-featured configuration and macro language to that application. This is roughly analogous to adding Visual Basic for Applications (VBA) to automate your work in Microsoft Excel.

This Is Just the Beginning

Once you learn PowerShell, you’ll be able to write scripts for any PowerShell-enabled system. Windows Server 2012 is shipping with over 2,300 cmdlets (the basic unit of PowerShell functionality), up from the 400 cmdlets that shipped with Windows 2008 R2.

On top of this, the number of PowerShell solutions provided from third parties and the user community is growing by leaps and bounds. To get an idea of what PowerShell’s future might hold, check out the sidebar “PowerShell Score Card, Ten Years On” to see what it has accomplished already in its 10-year history.

PowerShell Score Card, Ten Years On

• PowerShell v3 will ship with both Windows 8 and Windows Server 2012. There will be a version available for older Windows platforms.

• PowerShell v1 shipped in 2006.

• PowerShell v2 in 2009.

• WS2012 ships with over 2,300 cmdlets ready to use.

• PowerShell is integrated with SQL Server, IIS, Hyper-V, Microsoft Exchange, SharePoint, Server Manager, and much more.

• PowerShell is a stop ship event, meaning no Microsoft server product ships if it does not have a PowerShell interface.

• PowerShell supports running background jobs, running PowerShell scripts remotely, workflows, and much more.

• PowerShell is integrated with third-party companies like VMWare, Intel, Cisco, Citrix, Red Hat, and NetApp, among others.

• PowerShell has third-party tools like IDEs, Quest Software, Devfarm Software, Software/FX, and many more.

• The PowerShell console window runs in the browser, a.k.a. PowerShell Web Access (PWA).

• PowerShell has a thriving community with over 50 PowerShell MVPs (most valuable professionals), bloggers, podcasts, script repositories, active forums, and much more.

Why Use PowerShell

I use PowerShell for a number of reasons. It makes me fast, it’s easy to use, and it’s comprehensive. While PowerShell will never win a race with compiled .NET code, it’s fast enough.

Note

You can include .NET code directly in a PowerShell script and compile it on the fly.

PowerShell is an astonishing glue language because it is rooted in .NET. The .NET Framework, and the applications built on it, provides a set of powerful components that PowerShell can connect together. This includes the .NET applications I am building today. PowerShell pipes objects—not text—across the pipeline, enabling programming scenarios, in few lines of code, that were not possible before.

PowerShell is easy to learn and extremely powerful. It has all the elements you’d expect in a systems language—variables, loops, data structures, file I/O—and more. In addition, it has complete access to the .NET Framework, and the ability to seamlessly load .NET DLLs, instantiate objects, and retrieve metadata—either on your local box or via PowerShell remoting.

Finally, PowerShell is fun, satisfying, and rewarding to use. Whether you’re using it to automate a tedious task, to simplify an implementation complicated by traditional means, or to create GUIs (WPF or WinForms based), PowerShell reduces both the effort and time you spend to get to a completed program.

There’s a New Game in Town

Think of PowerShell as a new pinball game. We can continue to play the old one—we know how to jiggle the machine just right so as not to tilt it, we understand all the ins and outs, and we know the tricks to get extra plays—but this new game has great potential.

But there is a wrinkle here: in order to get good at PowerShell, you need to experience a short, frustrating period of being bad at it (i.e., the valley of the s-curve shown in Figure 1-1). That means you’ll be looking things up, wrapping your head around new ideas, and getting comfortable with the fact that when you jiggle PowerShell, sometimes it’s going to tilt.

Note

Usually you see declines in performance before significant improvements.

Figure 1-1. S-curve of innovation

An Underutilized Development Tool

Scripted versions of applications require less code, effort, and development time compared to traditional approaches. The interesting discussion is not static languages versus dynamic languages, but rather when and where to use both for delivering solutions. As John Ousterhout, creator of Tcl/Tk, put it:

Scripting languages are higher level than system programming languages in the sense that a single statement does more work on average. A typical statement in a scripting language executes hundreds or thousands of machine instructions, whereas a typical statement in a system programming language executes about five machine instructions.

In summary, you owe it to yourself to try out this new pinball machine.