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:
- Getting started with PowerShell
- PowerShell] as a better shell
- The syntax of the PowerShell language
- Listing the Targets in your MSBuild file
- Getting an overview of your code-base
- Shutting down the pesky virus scanner with WMI events
- Looking into your MongoDB data with PowerShell
- Freeing yourself from xml build languages with psake
- Testing your .NET code using Pester
- Automated UI testing with PowerShell
- Writing a Visual Studio extension in 1 line of PowerShell
- Using PowerShell to add Twitter and Jabber to VS
- Using chewie and nuget to automate adding and updating libraries
- Lightweight code generation with here string interpolation
- Rapid UI prototyping with Show-UI
- Automating debugging with WinDbg
- Basic monitoring with PowerShell
- Graphing monitoring data with PowerShell and gnuplot
- Automating deployments
- Automate smoke tests using PowerShell and VirtualBox
- Using PowerShell to configure your application
- 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.
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
- 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.
- Richard Siddaway’s Blog: Reaons to learn Monad
- TechRepublic: 10 reasons why you should learn to use PowerShell
- Technet: Scripting with Windows PowerShell
- Wikipedia: Windows PowerShell
- Cmdlet Overview
- Windows Powerhell Provider Overview
- Writing a Windows PowerShell Module
- Jeffrey Snover
- Expert to Expert: Erik Meijer and Jeffrey Snover - Inside PowerShell
- Going Deep
- Erik Meijer
- PS for .NET devs category