PS for .NET devs part 0: PowerShell what is it and why should I care?

Being a big PowerShell fan but not seeing many fellow developers around me use it, I thought PowerShell could use some promotion among .NET developers. This inspired me to start a series of blog posts showing the great stuff PowerShell has to offer .NET developers. The outline I have defined up to now looks like this:

  1. Getting started with PowerShell
  2. PowerShell] as a better shell
  3. The syntax of the PowerShell language
  4. Listing the Targets in your MSBuild file
  5. Getting an overview of your code-base
  6. Shutting down the pesky virus scanner with WMI events
  7. Looking into your MongoDB data with PowerShell
  8. Freeing yourself from xml build languages with psake
  9. Testing your .NET code using Pester
  10. Automated UI testing with PowerShell
  11. Writing a Visual Studio extension in 1 line of PowerShell
  12. Using PowerShell to add Twitter and Jabber to VS
  13. Using chewie and nuget to automate adding and updating libraries
  14. Lightweight code generation with here string interpolation
  15. Rapid UI prototyping with Show-UI
  16. Automating debugging with WinDbg
  17. Basic monitoring with PowerShell
  18. Graphing monitoring data with PowerShell and gnuplot
  19. Automating deployments
  20. Automate smoke tests using PowerShell and VirtualBox
  21. Using PowerShell to configure your application
  22. Using PowerShell as an extensibillity point

This should give you a sense of the breadth and depth that is available to you when you harness the power of PowerShell.

What is PowerShell?

Citing Wikipedia on Windows Powershell:

Windows PowerShell is Microsoft’s task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the .NET Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.

To expand on that a little PowerShell is built on .NET and uses the .NET object model to give it it’s competitive advantage. Tasks (Cmdlets as they are officially called) can be composed using the pipeline. Think of a UNIX shell but instead of text flowing through the pipelines, .NET objects flow through the pipelines. This relieves the user from “prayer based parsing” with tools like e.g. cut, sed, awk. Combine this with the reflection capabilities .NET has to offer, automatic (type) conversions, advanced parameter binding and you have a discoverable, composition friendly working environment. Quoting Jeffrey Snover, (the architect behind the product now responsible for the entire windows server platform): “It’s like programming with hand grenades.” Watch this great Going Deep episode and see how Jeffrey talks about this in detail with Erik Meijer.

Why should I care about PowerShell?

When I tried searching for the answer to this question I came up with a list of blog-posts that were all oriented toward the IT-pro. For reference I’ve included the links below in the References section. Apart from the hints given in the outline above on why you should care. You may find yourself writing a PowerShell module, Provider or Cmdlet to help your users interact with the application you are writing sooner than you think. When that’s the case it is crucial you have experience in PowerShell, especially since PowerShell requires you to abide to some specific naming conventions. Furthermore PowerShell users expect certain behaviors from the functionality you provide to be the same as they are accustomed to from using other Cmdlets and Providers.

The list of PowerShell features that are most useful for a .NET developer as far as I can come up with from the top of my head:

  • PowerShell is a better shell
  • PowerShell has very good support for working with xml
  • PowerShell is easy to learn
  • Powershell is an automation engine and a shell using a nice language
  • PowerShell can be used to quickly lookup methods and/or experiment with .NET types
  • PowerShell easily talks to COM
  • PowerShell can be used to query WMI, hookup to WMI events
  • PowerShell has a built-in registry provider, which means you can access the registry with the familiar dir, copy and del commands
  • for those doing web development, the IIS team provides a PowerShell module that covers 99% of IIS’s functionality
  • SQL Server 2008 and up have a very comprehensive PowerShell module that contains both a Provider and a set of Cmdlets.

I hope all of the above gets you intrigued and/or inspired to look into PowerShell, or at least to check back here for part 1 of this series. Until next time, wield your new found powers wisely.

Sun 19 Jun 2011