At my work I am starting to integrate PowerShell scripts into the TeamBuild projects for our nightly build. Including PowerShell is very easy: you just need to ensure that PowerShell is installed on the build server. Installing PowerShell will adjust the PATH environment variable, but you may need to restart the build service in order for the build server to pick up this new path.

Including a PowerShell script in your TeamBuild (or MSBuild) targets is very easy. You might have a target that looks something like this:

<Target Name="UnrestrictedExecutionPolicy">
    <Exec Command="powershell set-executionPolicy unrestricted&quot;" />
</Target>
<Target name="TestScript" DependsOnTargets="UnrestrictedExecutionPolicy">
    <Exec Command="PowerShell ./Scripts/testscript.ps1" />
</Target

As with most environments, we need to change the execution policy so that it will allow scripts to be run. We only need to do this once for our whole build, so best to create it in its own target and place a dependency to it from other targets that will be calling PS scripts.

In the above example, we are calling a script in the Scripts folder called testscript.ps1. Pretty simple really. If an error occurs in that script, then the exit code will indicate an error, and the build will fail. However, we may not want the build to fail. Perhaps only a warning is required. Or perhaps we want the script to do things that might break the build AND raise warnings. How can we handle this?

An easy way is to use exit codes. Most EXEC calls will return an exit code. 0 usually means success, and 1 or higher means failure. In MSBuild (ie. TeamBuild) that means 1 or higher will break the build. So what if we want our PowerShell script to return all sorts of exit codes, and only have certain exit codes break the build, and others raise warnings? This is easy too, but requires some jigging.

First, we call the EXEC task with an attribute that tells it to ignore the exit code that results from the call. This means that even failed calls will not break the build. Second, we capture the exit code of the EXEC task with the Output attribute and assign it to a Property. The target might then look like this:

<Exec Command="PowerShell ./Scripts/testscript.ps1" IgnoreExitCode="true">
     <Output TaskParameter="ExitCode" PropertyName="ScriptExitCode" />
</Exec>

Cool... we now have the exit code in the property 'ScriptExitCode' and can manually do what we like with it. Using the Warning and Error tasks that already exist, we can react in a more custom way:

<Warning Condition="$(ScriptExitCode)==2"
               Text="Warning: The script raised a warning" />
<Error Condition="$(ScriptExitCode)==1"
           Text="Error: The script raised an error: Build stopping." />

In this example, if the script returns exit code 1, the build still fails. However if it returns 2, then only a warning is raised, and the build continues on.

So only one thing remains: how do we tell PowerShell scripts to return a specific exit code? Well that's just as easy. In our PS script, we can use this line:

$host.SetShouldExit(2)

$host is a reserved variable in PowerShell. In the above code, we are telling the script to return exit code 2 when it exits. Note that this line does not tell the script to exit straight away. To do that, call the command 'exit'.

So using this knowledge, we can sprinkle the relative exit codes throughout our scripts and let MSBuild handle it on the outside.

Brisbane: A rich ecosystem of technology, enthusiasm, and deliverance. I often wonder how I manage to stay married when there is so much going on in this town that keeps me distracted. I'm sure its just as rich in other cities, but hell, I don't care about those infestations. Brisbane is great for the developer/enthusiast and here's why: my week since last Wednesday.

Weds 26th March - Heroes Happen
I was sitting in one of the Server 2008 sessions and I realised "I've seen all this before". It was at that point in time I remembered last year playing around with server 2008 beta 3 and TFS 2008. I had had so many problems, I'd reinstalled the server like 5 times, so I was very familiar with the interface. I was most interested in the Server Core and Hyper-V products and particularly interested in the Server 2008 license now sitting on my desk waiting to be installed. To be honest, I didn't learn much from the developer sessions. I've been using VS2008 for quite a while: both in production over the last 3 months, and beta last year with 'toy' projects. Still, Dave Glover showed a few cool things I hadn't seen before, such as the native debugger support for WCF apps, including the WCF test window.

Thurs 27th March - Sql Server User Group
The guys from Soul Solutions showed up to deliver some useful information on Sql Spatial. Unfortunately I couldn't stay from the whole event, but I hung around long enough to find out that John and Bronwen were in fact the 2 people dressed up as Batman and Batgirl at Heroes! Those 2 are crazy...

Mon 1st April - QUT Alumi Presentation
There was a few hours of work left when Joel Pobar came roaming through the pods trying to drum up interest in a presentation at QUT by Gordon Bell. The topic was around data and its management: how do we derive quality information? He covered briefly his history around the starting of the Microsoft Research Centre and the work done there in recent years around data management, in particular a case study into celestial data and the resulting Worldwide Telescope.

Tues 2nd April - Security Interest Group
A new user group that I only stumbled on as I was walking out the door at the end of the day, this group had a great presentation on Microsoft's product offerings and where security fits into the 'now' and 'future'. While MS product based, it was quite well generalised. I felt quite odd though being the only developer in a room full of system admin-type people! I'm very keen to see where this group goes from here (no link because they don't have a web site yet: hit me up if you want the administrators email, sorry I don't have it handy at the time of this post!).

Weds 3rd April - Briztalk User Group
This is the second time I have come to this group's meetings and have enjoyed them both greatly. The first was about RFID, and last night's was about the new 2008 offerings in Server and Visual Studio. The second talk was old news (again) but once again I felt fascinated by the infrastructure aspects of 2008 Server, and it was my questions (single handedly) that caused the group to finish 1 hour later than it should have! (sorry everyone)

So as you can see, Brisbane is a rich fertile ground of development. I've learnt so much over the last week, its ridiculous. Luckily the VSTS user group (was suppose to be Friday morning) was postponed, help give meaning to the weeks ahead! Next week looks rather quiet, which should be good because I have some interesting ideas around F# that I would like to explore.

See you at the next Brisbane community event.