It’s been more than a year since Powershell 1.0 is out. The way Powershell is marketed you’d guess that the only people using it are hard-core administrators who need to automate a lot of work across many machines.

Far from it, Powershell is useful to any serious developer and maybe even enthusiast user. Yes, it does administrative tasks well, but it’s also useful for automation of many other tasks too.

I’ve seen two scenarios lately where Powershell shines: builds (as in software builds) and throw-away helper projects.

I will discuss the current state of a couple of build systems in more detail in a another post, but I will say here that both NAnt and MSBuild are not the greatest possible tools for the problem. You need to face a bit more than a simple console or Windows Forms project to really see why complex build rules end up unreadable or quirky in either of just mentioned systems. I attribute this to the basic design flaw of both: NAnt and MSBuild are highly declarative XML files that are “interpreted” by an engine. In comparison, both rake (Ruby based) and Powershell are full fledged languages.

Thus expressing intent, especially complex rules, is a lot easier in Powershell than in MSBuild for example. You don’t have to fit into MSBuild limited set of tasks nor to build an extension task (this is a primary way to extend MSBuild) in C#, compile, deploy and reference the assembly with the extension in the MSBuild build file.

Example: what follows is a Powershell script that transforms XML using XSLT.

param ([string]$inputXmlFilePath = $(read-host "Please specify the input XML file"),
       [string]$xslFilePath = $(read-host "Please specify the XSLT file"),
       [string]$outputXmlFilePath = $(read-host "Please specify the output XML file"),
       [string]$xparam
)

$xslFilePath = resolve-path $xslFilePath 
$inputXmlFilePath = resolve-path $inputXmlFilePath 
$outputXmlFilePath = join-path (split-path $inputXmlFilePath) $outputXmlFilePath 

$xslt = New-Object System.Xml.Xsl.XslCompiledTransform
$xslt.Load($xslFilePath, [System.Xml.Xsl.XsltSettings]::TrustedXslt, (New-Object System.Xml.XmlUrlResolver))

if($xparam) {
  $argList = New-Object System.Xml.Xsl.XsltArgumentList
  $argList.AddParam("xparam", "", $xparam)
  $outStream = New-Object System.IO.FileStream $outputXmlFilePath, Create, Write
  $xslt.Transform($inputXmlFilePath, $argList, $outStream)
  $outStream.Close()
}
else {
  $xslt.Transform($inputXmlFilePath, $outputXmlFilePath)
}

It's a bit limited in the sense that it doesn't pass more than one extra parameter to the XSLT, but this can easily be remedied. Since Powershell can use any .NET class, it was trivial to build this.

Another scenario where I found Powershell useful is for small throw-away helper projects. Instead of cluttering your solution with these projects, you need one file in one of the projects and you’re done. The concrete example: I built a simple TCP/IP server that would listen on a port and when a client connects would serve a content of a text file “replaying” one of the real server/client sessions from before. Simple, effective, works.

Finally, if you haven’t, do yourself a favor and download PowerGUI. Personally, I don’t use the main GUI at all, just the script editor. But the editor works really well, is simple and has a killer feature – Powershell debugging. Happy scripting!