PowerShell for Developers

PowerShell was written first and foremost for Windows system administrators, and the benefits to this community are clear. It’s not as clear what developers should make of PowerShell.

Administrators can learn PowerShell as a shell first, and gradually transition from interactive use to scripting. They may learn PowerShell as their first programming language and not even give too much thought to the language per se. But a developer has to ask why and when to use PowerShell rather than another language, such as C#.

Doug Finke’s new book Windows PowerShell for Developers (ISBN 1449322700) is “for developers” in a couple ways. First, the style of the book is geared toward developers. The book is small, less than 200 pages, because the author assumes the readers are experienced Windows developers who want to focus on what PowerShell adds to what they already know. Second, the book focuses on tasks a developer might want to do. Rather than show you how to create a new Active Directory user, as many PowerShell books would, this book covers topics such as

  • code generation
  • static analysis
  • interfacing with C#
  • embedding PowerShell in your application
  • working with XML and JSON
  • interfacing with Excel
  • creating DSLs.

So why should software developers use PowerShell? And what tasks should they do in PowerShell? One answer to the first question, implicit in the book’s examples, is that PowerShell makes it possible to carry out common tasks with little code. Another answer explicitly given in the book is integration.

Given PowerShell’s growing integration with the rest of the Windows platform, as PowerShell grows, so does your application.”

The book is full of examples of what tasks a developer might want to do in PowerShell. The examples I found most interesting were embedding PowerShell to provide a scripting language for your application and creating DSLs in PowerShell.

One pattern in the examples is text munging, whether that text is source code or common data file formats. Another pattern is integration, especially integrating Microsoft technologies. PowerShell is designed to make it possible to solve these kinds of problems with a minimum of ceremony.

I’ll close with a couple reasons why might a developer not want to use PowerShell in my opinion. The first is frequency of use. Although PowerShell can solve many problems with significantly less code than C# would require, you have to learn PowerShell first, and you have to use it frequently enough to remember it. You have to use PowerShell enough to repay the time invested in learning and practicing it.

The second reason is size. The C# language and the Visual Studio IDE were designed for large projects, but scale down fairly well for smaller projects. PowerShell was designed for the command line, but scales fairly well for large scripts. If you use PowerShell and C#, you’ll have to decide at what size you want to switch from one language to the other.

Related posts

Giveaway: PowerShell in Depth




Related links:

Learn PowerShell as a shell first

When I was learning PowerShell, I thought of it as a scripting language that has a shell. But the right way to think of it may be the opposite, a shell that has a scripting language. Apparently others have followed this same change of perspective.

Don Jones and Jeffrey Hicks open their new book Learn Windows PowerShell 3 in a Month of Lunches by explaining that they first saw PowerShell as a VBScript replacement and taught it that way.

Since late 2009, however, a shift has occurred. More and more administrators who don’t have prior VBScript experience have started trying to learn the shell. All of a sudden, our old teaching patterns didn’t work very well, because we focused on scripting and programming. That’s when we realized that PowerShell isn’t really a scripting language. It’s really a command-line shell where you run command-line utilities. Like all good shells, it has scripting capabilities, but you don’t have to use them, and you certainly don’t have to start with them.

[Don Jones wrote the first edition of the book, which I haven’t read. This quote comes from the second edition, coauthored with Jeffrey Hicks.]

Other PowerShell books I’ve read felt more like a programming language book than a book on a shell, more like, for example, The C Programming Language than The Linux Command Line. The latter seems to be a better analog for the new PowerShell 3 book: emphasis on interactive use first, programming second. At least that’s my first impression. The book isn’t finished yet—it’s part of Manning’s Early Release program—and I haven’t yet read all of the part that has been released.

If you’d like a chance to win a copy of Learn Windows PowerShell 3 in a Month of Lunches, please leave a comment below. I’ll draw a winner and the publisher will send you a copy of the book.

Update: I’ll draw a winner on Friday, June 29. Comments need to be posted by midnight Thursday in my time zone.

Related links:

Scripting and the last mile problem

From Bruce Payette’s book Windows PowerShell in Action:




Related post:

Updating “PowerShell Day 1” for PowerShell version 2.0

Last year I wrote a little 10-page booklet called PowerShell Day 1. It covers many of the things I wish I had known when I started using PowerShell.

  • How do I configure PowerShell?
  • How do I make PowerShell launch faster?
  • How do I get documentation?
  • Why did PowerShell make some of the design decisions they did?
  • Once I’ve written some useful functions and scripts, where do I put them?
  • Where can I find more PowerShell resources?

Now I’ve started updating the booklet to reflect changes in PowerShell version 2.0. I haven’t had a lot of experience with version 2.0 and would appreciate your help updating the booklet. I have put a link to an alpha version of the update for version 2.0 on the download page.

PowerShell 2.0 for Windows XP etc.



I expected something more like the following.

PowerShell 2.0 Released

Download for your platform:

  • XP
  • Vista (32 bit, 64 bit)
  • Server 2003 (32 bit, 64 bit)
  • Server 2008 (32 bit, 64 bit)

Related links:

Finding embarrassing and unhelpful error messages

Every time your software displays an error message, you risk losing credibility with your users. If the message is grammatically incorrect, your credibility definitely goes down a notch. And if the message is unhelpful, your credibility goes down at least one more notch. The same can be said for any message, but error messages are particularly important for three reasons.

  1. Users are in a bad mood when they see error messages; this is not the time to make things worse.
  2. Programmers are sloppy with error messages because they’re almost certain the messages will never be displayed.
  3. Error conditions are unusual by their very nature, and so it’s practically impossible to discover them all by black-box testing.

The best way to find error messages is to search the source code for text potentially displayed to users. I’ve advocated this practice for years and usually I encounter indifference or resistance. And yet nearly every time I extract the user-visible text from a software project I find dozens of spelling errors, grammar errors, and incomprehensible messages.

Last year I wrote an article for CodeProject on this topic and provided a script to strip text strings from source code. See PowerShell Script for Reviewing Text Shown to Users. The script looks for all quoted text and text inside XML entities. Then it tries to filter out text strings that are not displayed to users. For example, a string with no spaces is more likely to be a file name or some other code fragment than a user message. The script produces a report that a copy editor can then review. In addition to checking spelling and grammar, an editor can judge whether a message would be comprehensible and useful.

I admit that the parsing in the script is crude. It could miss some strings, and it could filter out some strings that it should keep. But the script is very simple, less than 100 lines. And it works on multiple source code types: C++, C#, XML, VB, etc. Writing a sophisticated parser for each of those languages would be a tremendous amount of work, but a quick-and-dirty script may be 98% as effective. Since most projects review 0% of their source code text, reviewing 98% is an improvement.

In addition to improving the text that a user sees, a text review gives some insight into a program’s structure. For example, if messages are repeated in multiple files, most likely the code has a lot of “clipboard inheritance,” code copied and pasted rather than isolated into reusable functions. A text review could also determine whether a program is concatenating strings to build SQL statements rather than calling stored procedures, possibly indicating a security vulnerability.

PowerShell news

I found out some PowerShell news by listening to the PowerScripting podcast this morning. Here are a couple things I found interesting. See the podcast show notes for more news.

First, a new version of the PowerShell Community Extensions came out last week, version 1.2. See Keith Hill’s summary of the changes.

Second, Bruce Payette is working on a second edition of his book PowerShell in Action. You can get an “early access” version of the book through the publisher, Manning.

Adding fonts to the PowerShell and cmd.exe consoles






Run regedit.exe and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionConsoleTrueTypeFont.



Related posts

Comparing the Unix and PowerShell pipelines

This is a blog post I’ve intended to write for some time now. I intended to come up with a great example, but I’ve decided to go ahead and publish it and let you come up with your own examples. Please share your examples in the comments.

One of the great strengths of Unix is the shell pipeline. Unix has thousands of little utilities that can be strung together via a pipeline. The output of one program can be the input to another. But in practice, things don’t go quite so smoothly. Suppose the conceptual pattern is

A | B | C

meaning the output of A goes to B, and the output of B goes to C. This is actually implemented as

A | <grubby text munging> | B | <grubby text munging> | C

because B doesn’t really take the output of A. There’s some manipulation going on to prepare the output of A as the input of B. Strip these characters from these columns, replace this pattern with this other pattern, etc. The key point is the Unix commands spit out text. Maybe at a high level you care about programs A, B, and C, but in between are calls to utilities like grep, sed, or awk to bridge the gaps between output formats and input formats.

The PowerShell pipeline is different because PowerShell commands spit out objects. For example, if the output of a PowerShell command is a date, then the command returns a .NET object representing a date, not a text string. The command may display a string on the command line, but that string is just a human-readable representation. But the string representation of an object is not the object. If the output is piped to another command, the latter command receives a .NET date object, not a string. This is the big idea behind PowerShell. Commands pass around objects, not strings. The grubby, error-prone text munging between commands goes away.

Not all problems go away just because commands pass around objects. For example, maybe one command outputs a COM object and another takes in a .NET object. This is where more PowerShell magic comes in. PowerShell does a lot of work behind the scenes to implicitly convert output types to input types when possible. This sort of magic makes me nervous when I’m programming. I like to know exactly what’s going on, especially when debugging. But when using a shell, magic can be awfully convenient.

* * *


UnixToolTip twitter icon