One of the cool benefits you get with PowerShell is the ability to make use of external .NET assemblies. Lately I found myself wanting to do some scripting involving an iCalendar feed, and since I hate writing console applications every time I have some small task to perform, PowerShell seemed like a good choice. While there is no built-in support for consuming iCalendar files, the ability to augment it with an assembly meant that I could import the DDay.iCal library I’ve used before in other .NET projects.

For this example, I had a calendar I was using in Google Calendar to track my weight. Eventually it just became a long list of numbers that would be far more interesting if they were charted. This seemed like a good chance to give the Google Chart API a spin as well.

So let’s get started. Any assemblies loaded into the .NET GAC will automatically be made available in PowerShell. For anything else, you can load it via the DLL:

[Reflection.Assembly]::LoadFile("path\\to\\DDay.iCal.dll")

And just like that, we now have full iCalendar access from our script. Now it’s time to load up the calendar and process it, sorting the events chronologically.

$calendar = [DDay.iCal.iCalendar]::LoadFromUri("http://path/to/your/calendar")[0]
$sortedEvents = $calendar.Events | Sort-Object @{Expression={$_.DTStart.Value}; Ascending=$true}

I won’t go into much detail as far as how the Google charts work so I’ll just go through my (very simplistic) implementation pretty quickly. The basic idea is that I wanted to insert blank values for any dates where I didn’t have a value, so the chart would more accurately represent the time. Since it would be messy to throw a date label on every point, I decided to just label the first of every month. Here’s the function to do that:

function GetLabelFromDate($date)
{
    if ($date.Day -ne 1)
    {
        return ""
    }

    $date.ToString("MMMM")
}

Next up, we’ll prepare the chart values and labels. Since the simpler options for Google Charts impose limits on y-axis values and I had no real need to do anything more complicated, I use my own axis minimum and maximum, and scale the values accordingly.

$values = @()
$labels = @()
$chartMin = 190
$chartMax = 220;
$valueModifier = 100 / ($chartMax - $chartMin)

# process the events in the calendar
foreach ($event in $sortedEvents)
{
    $currentDate = $event.DTStart.Value

    $currentValue = ($event.Summary - $chartMin) * $valueModifier

    if ($lastDate)
    {
        # if there's a gap in the dates, fill it in with empty data
        while ($lastDate.AddDays(1) -lt $currentDate)
        {
            $lastDate = $lastDate.AddDays(1)

            $values += 0
            $labels += GetLabelFromDate $lastDate
        }
    }

    $labels += GetLabelFromDate $currentdate
    $values += $currentValue

    $lastDate = $currentDate
}

# figure out the size of the chart and bars
$chartWidth = 800
$chartHeight = 350
$barWidth = [Math]::Floor($chartWidth / $values.length)

Now we have the values and labels, so all we need is a chart to put them on. To do that, we need to construct the URL. Refer to the Google Charts API for documentation on what the specifics mean.

# Reference: http://code.google.com/apis/chart/docs/gallery/bar_charts.html
$url = "http://chart.apis.google.com/chart?cht=bvg&chs=$($chartWidth)x$($chartHeight)&chbh=$($barWidth),0,1&chd=t:$([String]::Join(",", $values))&chco=cc0000&chxt=x,y,r&chxl=0:$([String]::Join("|", $labels))&chxr=1,$($chartMin),$($chartMax)"

To download and display the chart, we’ll use the standard .NET WebClient class to do the heavy lifting, and download the file into my temp folder. Once it’s downloaded, the Invoke-Item cmdlet will use the default program assigned to PNG files to open it, which in my case is just the usual Windows Photo Viewer.

$filename = "$env:temp\weight-chart.png"
$webClient = new-object System.Net.WebClient
$Webclient.DownloadFile($url, $filename)

Invoke-Item $filename

Now we have a script that will load a calendar, process the data, and chart it. Of course that’s not all the DDay.iCalendar library is capable of, or any other library you feel like importing into your script. This is just one example of how you can use existing libraries in new and interesting ways.

Often I find that the last thing I want to look at is yet another new language to learn, but PowerShell is proving itself to be very useful for writing up Windows scripts, particularly when you want to interact directly with Microsoft services. In my project I have several web applications set up in IIS, and my version control structure has the trunk and an arbitrary number of branches. Whenever I would want to switch to working on a different branch of the code, I would need to reset the IIS applications to point to the new path; this quickly became more tedious than I like.

This seems like a good example to show what a very simple PowerShell script can do. I’m not going to cover how to set up PowerShell, but I will say that if you are on Windows 7, it’s already there waiting for you. For this example, you also need to make sure you have the IIS PowerShell module set up.

With that out of the way, let’s get started. As I mentioned before, the directory structure of my repository is very simple, as shown in the picture to the right. And no, I don’t really name my projects WebApplication1 and WebApplication2. The script I wanted to build was very simple: provide a menu of versions it finds, and let you pick which one to set IIS to use.
If you’re new to using PowerShell with IIS, one interesting aspect of it is the ability to browse IIS via the command line as if it were just another drive on the system. For example, let’s take a look at the current settings before we get started:

PS C:\Users\Greg> dir 'IIS:\Sites\Default Web Site'
Name             Application pool   Protocols    Physical Path
----             ----------------   ---------    -------------
WebApplication1  DefaultAppPool     http         C:\svn\trunk\WebApplication1
WebApplication2  DefaultAppPool     http         C:\svn\trunk\WebApplication2

First things first; we import the IIS library and set up the main variables used in the script:

Import-Module WebAdministration

# set this to the root folder, which contains 2 folders: "branches" and "trunk"
$svnPath = "c:\svn"

# paths to the branches
$branches = Get-ChildItem ($svnPath + "\branches")

# path to IIS website we are looking to configure
$iisPath = "IIS:\Sites\Default Web Site\"

$options = @{}
$optionCounter = 1

Most of that is pretty straightforward, but I’ll comment on some of it. Get-ChildItem is a PowerShell Cmdlet to list the child items in a location, which in our case is the folder of branches. The syntax used to declare $options creates it as an empty hash table.

Next, we’ll add some code to print out the options you can pick from. I make the assumption that the trunk will always be there, and then list the branches found in the previous section. There is nothing particularly interesting in this part:

# Print out trunk/branch options
write-host "Select which version you want to use in IIS:"
write-host ""

write-host "1: Trunk"
$options.Add($optionCounter.ToString(), ($svnPath + "\trunk"))

write-host "---------------------"
write-host "Branches:"
write-host ""

foreach ($branch in $branches) {
    $optionCounter++
    $options.Add($optionCounter.ToString(), $branch.FullName)

    write-host "$($optionCounter): $($branch.Name)"
}

write-host ""

As you can see, the write-host command is used to write out to the console. Similarly, read-host is used to get input from the user. We loop until you either pick a valid option in the menu, or decide to quit:

# Let the user pick an option
$input = ""

do {
    $input = read-host ‘Choose a version ("quit" to cancel)’
} while ($input -ne "quit" -band $options.ContainsKey($input) -eq $False)

# if they wanted to quit, we're done
if ($input -eq "quit") {
    exit
}

write-host ""

Now we’ve displayed a menu, and chosen which version of the applications we want to use in IIS. Finally, it’s time to update the actual IIS settings. In this example, I will include a hardcoded array of projects to use, but this could just as easily be made dynamically. For now we’ll keep it static to have total control on which applications this is applied to.

# now we can start updating IIS settings
$appPath = $options.Get_Item($input)
$projects = ("WebApplication1", "WebApplication2")

foreach ($project in $projects) {
    write-host "Updating: $($project)"

    Set-ItemProperty ($iisPath + $project) -name physicalPath -value ($appPath + '\' + $project)
}

write-host ""
write-host "Done!"

There, we use the Set-ItemProperty Cmdlet to update the physical path on each application in IIS. As I mentioned earlier, the IIS PowerShell module allows you to treat IIS applications as you would normal files in a folder, so that’s what we leverage here. You could use the same approach to set any other aspect of the application as well.

Here is sample output from running the script:

PS C:\Users\Greg> powershell.exe .\Set-IIS-Paths.ps1
Select which version you want to use in IIS:

1: Trunk
---------------------
Branches:

2: 2010-01-01
3: 2010-01-15

Choose a version ("quit" to cancel): 2

Updating: WebApplication1
Updating: WebApplication2

Done!

And there you have it. There is nothing groundbreaking here, and it only scrapes the surface of what you can do with both PowerShell and IIS, but it shows how simple it can be to write scripts to make your life easier, leaving more time to spend on doing the work you want to be doing. PowerShell also provides the ability to build rich user interfaces through WPK, available as part of the PowerShell Pack. I’ll leave it as an exercise for the reader to convert this into a GUI.