PowerShell Not Just IT’s Command Line Part 5 of 31: What’s in it for Devs?

My friend Matt Hester and I are doing a 31 days of PowerShell series this month, and now he’s letting me write! The name of our series is “PowerShell Not Just Your Father’s Command Line”, but today’s post is taking its own name (sorry, Matt!). That’s because many developers that I know are quick to dismiss PowerShell as yet another scripting language that IT people should know and that they might care about if they want to automate some of their own scripts. However, there’s so much more to PowerShell than just another scripting language.

As developers, we can zip through the PowerShell syntax and write scripts to automate deployment tasks. Maybe you have to deploy your code – be it a website, web application, web service, or some other piece of code – to multiple servers. Rather than running a script on each server individually, you may be able to take advantage of PowerShell 2.0 and its remoting features.

My favorite thing that I can do as a developer is writing custom cmdlets, modules, and providers for others to use. While I can write some of them in PowerShell, I can also write my customizations in C#, which is my language by day (currently).

A cmdlet called New-Beer may look something like this under the covers:

[Cmdlet(VerbsCommon.New, "Beer")]
    public class NewBeer: Cmdlet
    {
        private string _beername;
        private string _beertap;

        [Parameter(Mandatory = true,
     HelpMessage = "Type of beer to create",
     Position = 0)]
        [ValidateNotNullOrEmpty]
        public string BeerName
        {
            get { return _beername; }
            set { _beername= value; }
        }

        [Parameter(HelpMessage = "Tap for the beer (optional)")]
        public string BeerTap
        {
            get { return _beertap; }
            set { _beertap= value; }
        }

        protected override void ProcessRecord()
        {
            if (string.IsNullOrEmpty(BeerTap)){
                 // Create a new beer that can go on the next open tap
            } else {
               // Put a new beer on a specific tap
            }
        }
    }

If you wanted to call New-Beer (and celebrate Cinco de Mayo today), you could do something like this:

New-Beer -BeerName "Cerveza de Cinco de Mayo"

In this hypothetical (yet, festive!) example, this would add the “Cerveza de Cinco de Mayo” to the next open tap.

Now in reality, perhaps you have your business objects or data layers encapsulated in .NET objects that your IT folks may need in scripts. You can create your own functions, cmdlets, and providers with the help of System.Management.Automation. We will dive a little deeper with this later in our blog series.

You can also create GUIs for PowerShell scripts. So maybe, as a developer, you have an end user who isn’t comfortable in the console, but you find that it’s easiest to get what they need via a quick PowerShell script. You can get your data via PowerShell and then create a GUI for them. Whether you need to use WPF or WinForms is up to you, but both options are there. We will look into the specifics of creating GUIs later in this series.

Do you have specific questions about PowerShell that you want answered? Whether it’s IT pro related or developer related, I can probably help! Drop me a line at sarah at codinggeekette dot com, and I’ll try to cover your questions in an upcoming blog post.

Matt and I love feedback from our readers, so please email us if you have comments or suggestions.

2 thoughts on “PowerShell Not Just IT’s Command Line Part 5 of 31: What’s in it for Devs?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>