Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Getting Started with PowerShell – Developer Edition

PowerShell Unix-style Recently I was on the PowerScripting Podcast hosted by Hal Rottenberg and Jonathan Walz. I had a great time talking about PowerShell from a developer’s perspective and psake, my PowerShell-based build system, in particular. You can find the interview on Episode 56 here. Thanks to Hal and Jonathan for having me on the show.

Now let’s talk PowerShell and scripting for developers. I don’t see a lot of developers using the command line and this surprises me. Maybe it’s my Unix background that attracts me to the command line. Maybe it’s my belief that sustainable, maintainable development is facilitated by a CI process, which necessitates being familiar with the command line. Maybe it’s because the only way to create reproducible results is to automate and the easiest way to automate is the command line. Whatever the reason, I believe that developers should become familiar with copying, building, deploying, and otherwise automating tasks via the command line.

So why PowerShell? PowerShell is a full-fledged programming language focused on object-based shell scripting. Note that I didn’t say “object-oriented”. You cannot create class hierarchies or define polymorphic relationships, but you can instantiate and use objects defined in other .NET-based programming languages (or COM objects). PowerShell is a shell language, meaning that it serves the same role as cmd.exe, bash, tcsh, etc. It’s raison d’etre is automating the command prompt. Manipulating directories/files, launching applications, and managing processes is really straightforward.

Microsoft is investing heavily in PowerShell and providing support for managing Windows Server 2008, IIS7, SQL Server 2008, Exchange 2007, and other Microsoft server products. This means that we are approaching the Nirvana that is end-to-end build to deploy. Imagine getting latest from your source repository, building the code, unit/integration testing the code, building the documentation, labelling the build, and deploying into a QA environment! The entire process is automated and reproducible. You know the exact version of the code that went into QA. When you get the green light to do a live deployment, you give the same PowerShell scripts to the IT deployment team who uses it to deploy the compiled (and QA’d) bits into the production environment! Who best to write these deployment scripts than your friendly neighbourhood IT Pro, who is intimately familiar with the production and QA environments. This is a great collaboration point to get the IT Pros, who will be deploying and maintaining your apps, involved in the development process.

Enough chitchat. Show me the code! Believe it or not, you probably already know a fair amount of PowerShell. Many of the commands you’re familiar with in cmd.exe work in PowerShell. (More surprisingly, many of the common commands you know from bash, tcsh, or other Unix shells also work!) The command line arguments are often different, but the basic familiar commands are there. So try out dir, cd, copy, del, move, pushd, popd, … (If you’re a old Unix hacker, you can try out ls, man, kill, pwd, ps, lp, cp, … Unfortunately there is no grep equivalent built in, which is terribly unfortunate.) All of these commands are actually aliases to PowerShell commands, which are named by VERB-NOUN, where NOUN is singular. For example to get a list of running processes, you run Get-Process, which is aliased to “ps”.

PowerShell is very conducive to experimentation. You can always find out more about a command or alias typing “Get-Help [CmdName|Alias]” or simply “help [CmdName|Alias]” since help is an alias for Get-Help. (N.B. PowerShell is case insensitive.) You can also look for commands by typing part of the command and pressing tab repeatedly. For example, if you want to find all set- commands, type “set-[TAB][TAB]…” to display Set-Acl, Set-Alias, etc. You can also look for commands using wildcards. Type “*-Acl[TAB][TAB]…” displays Get-Acl and Set-Acl.

So start playing around with PowerShell. Learn what it can do for you. Next time, we’ll look at writing re-usable scripts for accomplishing common developer tasks. Until then, happy scripting!

About James Kovacs

James Kovacs is a Technical Evangelist for JetBrains. He is passionate in sharing his knowledge about OO, SOLID, TDD/BDD, testing, object-relational mapping, dependency injection, refactoring, continuous integration, and related techniques. He blogs on CodeBetter.com as well as his own blog, is a technical contributor for Pluralsight, writes articles for MSDN Magazine and CoDe Magazine, and is a frequent speaker at conferences and user groups. He is the creator of psake, a PowerShell-based build automation tool, intended to save developers from XML Hell. James is the Ruby Track Chair for DevTeach, one of Canada’s largest independent developer conferences. He received his Bachelors degree from the University of Toronto and his Masters degree from Harvard University.
This entry was posted in PowerShell. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    This is a great collaboration point to get the IT Pros, who will be deploying and advancement your apps, complex in the development process.

  • http://www.jameskovacs.com james.kovacs

    @Chris – I didn’t know that (obviously). Definitely adding select-string to my repertoire!

    @Morten – The reality is that although you can write a UI over a command line tool with relative ease (think VS driving MsBuild), writing a command line tool over a GUI tool is well near impossible. I’m sure you’ll see visual tooling, either by Microsoft or a third-party, that will wrap the tasty PowerShell goodness in a comfortable GUI coating.

  • http://www.bluespire.com/blogs Christopher Bennage

    @James I’ve been interested in learning more about PS for some time now. Please keep these coming!

  • static_readonly

    Really looking forward to the rest of this series.

  • Morten

    The problem with PowerShell is, that many functions like in Exchange 2007 now only is available through PowerShell and not by calling an API. This is good if you like to run your administration from the command line, but what if you want to do it through managed code? This can be done yes, but it is not very efficient.
    Powershell is in my opnion not what all systems administrators want as you cannot put these scripts in the hands of someone who has a little knowledge and frankly using a command prompt this is a step back in time. I do not know what drowe Microsoft in this direction, internal Unix freaks?, but they surely forgot to ask the people who are using their systems.

  • http://www.tavaresstudios.com Chris Tavares

    There is a GREP equivalent – select-string