I’ve decided to spend part of this weekend organizing my sock drawer PowerShell profile, and since there doesn’t seem to be a lot of best practices or prescriptive advice on setting up your PowerShell profile, I thought I’d write about how I do it, to help any new users out there get started.

If you are a .Net developer or a Computer Science researcher, and haven’t started using PowerShell, let me just make this argument for learning it:

PowerShell cmdlets are simple to write. The additional code required to make a .Net class into a cmdlet is very minor (at a minimum, a single method with a line of code to Write-Output something). Since cmdlets must derive from either Cmdlet or PSCmdlet you can’t just write every class as a cmdlet, but even non-cmdlet classes can be instantiated via New-Object and their methods and properties can be exercised.

After writing portions of a recent research project as PowerShell cmdlets, I would say that the ability to write a simple class and then use/execute from the command line and in scripts — plus the built in automatic argument parsing (PowerShell assigns pipeline input and command line parameters to object properties for you) makes PowerShell cmdlets quite useful for research and development. Because the overhead is so minimal, it minimizes the distractions of creating a user interface and allows you to focus your actual research goals. Additionally, because the PowerShell-specific code can be restricted to attributes and a method or two, the actual classes are still usable for other purposes. That is, your class is invokable within PowerShell, but it’s also reusabe within any .Net application, whether Windows.Forms, WPF, or even web apps.

Of course, since I’m primarily using PowerShell for research and development, I’m using the current CTP 2 release of PowerShell v2, some of what I’m doing in my profile won’t work until PowerShell 2 is released (next year?). I’ll try to mark the CTP-only features appropriately and offer PowerShell 1-compatible workarounds.

The first step, of course, is to install the software. To take full advantage of PowerShell 2, you need to have the .Net Framework 3.5 although you could use the .Net Framework 2.0 instead if you’re just using PowerShell 1.0. PowerShell 1 is only available as a “patch” so you have to choose the correct download for your platform through the Microsoft Download Center. However, since it’s still in CTP release, there is an installer for PowerShell 2 CTP2.

I also use the PowerShell Community Extensions and recommend them, although there’s a lot in there you may not use, there’s also a lot of extremely useful things — some of which are practically requirements. This package needs updating to work well with PowerShell 2, because PowerShell 2 has implemented natively some of the most popular features in PSCX, but it’s just a few minor changes. If you’re just getting started (or want to follow along with this series of posts), you should let PSCX install it’s profile (if you already have a profile, then in order to follow along with these posts, you should MOVE your profile out of the way before you install PSCX, and go ahead and let it create a profile from scratch).

Part 2