PowerShell, Visual Studio and You

Recently I needed to write up a new Powershell script to automate some actions independently of our major release cycle.

This took me down a road with two possible options – write the script in Visual Studio 2012 or in Visual Studio 2010.  I’ve decided to pursue both avenues, just for kicks.  There are other options available, but I’m more comfortable with Visual Studio, and it integrates into our standard SDLC tools (Team Foundation Server), so I can associate the work to work items, e.t.c.

This article will cover writing PowerShell scripts in Visual Studio 2010 using PowerGUI and the PowerGUI VSX (Visual Studio Extension).  I’ll attempt a follow up showing how to accomplish the same outcome with Visual Studio 2012 later.

Be kind.. This is my first foray into the world of PowerShell scripting..  Just posting a few observations.

Installing Software For Visual Studio 2010

The first thing you need is Quest PowerGUI (my chosen PowerShell add-in) version 3.2 – note that this is not the latest version, 3.6!.  Unfortunately, the Visual Studio extension only supports version 3.2.  This required a little bit of Google-Fu, but I found a copy here on the PowerGUI forum.

You’ll also need PowerShell 2.0 installed (if not already installed), you can install from the Microsoft site.

Once installed, use Visual Studio’s Extension Manager (under Tools) to search for (in the online templates) the PowerGUI VSX extension and install.  Once done, you’ll need to restart your instance of Visual Studio.

Once restarted, when you look under the File->New Project, you’ll see a new option for Powershell (note I have two VS extensions installed):

Once installed you can create a new project and we can start our scripting.

PowerShell

Well, I won’t go into too much detail here.  Once everything’s installed, you can create a new PowerShell project, which really just creates a project and allows you to add new PowerShell script files.

The main advantage here is the debugging and IntelliSense support, which really helps let you know if things are being written properly.  I did the majority of scripting within Visual Studio, although PowerGUI has a separate script application which isn’t bad.

PowerShell Challenge No.1

OK, so here’s what I was attempting to do.  From a given directory, iterate through XML files and read out the contents of each file.  For each file, the aim was to hit a WCF (SOAP) web service and store the XML data from the files.

Pretty basic stuff?  Agreed.  So I decided to tackle the trickiest part first.  Using Visual Studio was a bit of a help, because the IntelliSense gave me a good hint when the script was written properly.

Invoking a WCF Web Service from PowerShell

There’s actually an extremely straightforward way of doing this provided that the service is using a HTTP endpoint.  There’s a cmdlet in PowerShell 2.0 called New-WebServiceProxy which simplifies the calls to child’s play.

Let’s say I had a Web Service called FormManagement which had an operation called Save.  The Save operation takes two parameters, a string param called “AppNumber” and a string for the form data.  Assuming I had this service configured with basicHttpBinding and no authentication, to invoke the Save() operation from PowerShell I’d just do this:

$uri   = “http://tempuri.org/Forms/FormManagement.svc”
$proxy = New-WebServiceProxy -uri $uri

Write-Output $appNumber
$proxy.Save($appNumber, $formData)

For all other cases – particularly when using a net.Tcp endpoint – (and potentially if you have dramas with wsHttpBindings) you’ll have to deal with programmatically creating at runtime a client proxy assembly to get the type goodness.  Luckily, someone else has a very elegant solution which is worth a look.

The Rest

Is Child’s play.  In fact, I wrote the logic into functions just because I can.  Essentially, I’m using a global variable ($directory) which is referenced by the Process-Folder function.  The rest is really too trivial to go into detail.

function global:Process-Folder()
{
    $files = Get-ChildItem $directory -Filter *.xml -Name
    foreach ($file in $files)
    {
        $processing = “Processing file: ” + $file
        Write-Output $processing
        Process-File $file
    }
}

The Process-File function takes a filename parameter and takes care of prepping the input data for the Web Service call in the previous section.

function global:Process-File
(
        [CmdletBinding()]
        [Parameter(Position=1, Mandatory=$true)][string] $fileName)
{
    $appNumber = $fileName.ToUpper().Replace(“.XML”, “”)
    $fqn = $directory + $fileName
    $formData = Get-Content $fqn #TODO: flatten the string array into a single string
   
    #Invoke the WCF service
}

It’s almost elegant.  Not bad for a first script?  I’ll be doing a second article on how to work with PowerShell in Visual Studio 2012.