Psake is a PowerShell based process automation tool that can be used to automate a large variety of tasks. In this series, we explore the different ways that Psake can be used to streamline your development process. We’ll see how to use it to specify version numberes, run builds, execute tests, report on test coverage, and more.

An Introduction to Psake

Saturday, July 29 2017 psake powershell

There are a lot of benefits to the automation of tedious and/or error prone activities. With suitable preparation, we can dramatically speed things up while reducing the rate of errors considerably. In some cases, we can eliminate errors completely. For all this, it can sometimes be difficult working out where to start.

Read more »

Finding MSBuild

Saturday, August 05 2017 psake powershell

One of the goals of build automation is to create a robust and reliable process that can be depended upon. To achieve this, our build script needs to be smart, transparent and maintainable.

Read more »

Readable output from a build

Saturday, August 12 2017 psake powershell

It’s important to make it easy to understand what our build script has done. A failing build is always a troublesome distraction at an inconvenient time, so we need to make it as easy as possible to identify the problem and move on.

Read more »

Unit Testing

Saturday, August 19 2017 psake powershell

A push button build script that does exactly one thing isn’t that useful - we could achieve as much by building from within Visual Studio itself. The benefits of build automation begin to accrue when we start orchestrating multiple steps. Let’s extend the script to automatically run all our unit tests.

Read more »

Controlling build types

Saturday, August 26 2017 psake powershell

While it’s not strictly required by this project, let’s look at what would be required to set up different build targets for different purposes. Currently our Compile.Assembly task just compiles whatever defaults are baked into the project. Let’s change that so we can specify whether we want Release or Debug builds.

Read more »

Launch Scripts

Saturday, September 02 2017 psake powershell

To simplify the use of our build scripts, and to make it easier for someone new to the project to work out how things work, we’ll create some convenience PowerShell scripts to launch the build. We’ll create three scripts, for three different purposes: one for moment to moment use by a local developer; one to do a release build when the project is ready for distribution; and one for our continuous integration server.

Read more »


Saturday, September 09 2017 psake powershell

Version numbering is an odd detail - one we can (and should) easily ignore at the start of a project. There comes a point, however, where we find that version numbering is vitally useful. At that point, we usually discover that we should have started versioning things about six months ago … and now we have a mess to clean up.

Read more »

Semantic versioning

Saturday, September 16 2017 psake powershell

Perhaps the most significant problem with the simplistic versioning system we put into place last time is that we can get the same version number generated on different branches. Fortunately, semantic versioning gives us room to fix this by adding a descriptive suffix to the build number.

Read more »

NuGet packaging

Saturday, September 23 2017 psake powershell

While NuGet provides all the power needed to explicitly control every aspect of a package (something the exacting control freak in me really appreciates), a simple project like this doesn’t need anything more than the standard conventions.

Read more »

Test Coverage with Opencover

Saturday, September 30 2017 psake powershell

Once you have a reasonable suite of unit tests, you might start to wonder how much of your code is properly tested. Measuring coverage gives one perspective, and it’s one we can easily add to our builds.

Read more »

Test Coverage Reporting

Saturday, October 07 2017 psake powershell

Building on our previous post, we can take the coverage information generated by OpenCover and generate a report that shows us where our coverage is lacking.

Read more »

.NET Core Builds

Saturday, October 21 2017 psake powershell

Part way through writing this series, I decided to convert the Niche.CommandLine project to .NET Core, which of course required a bunch of changes to the Psake build script. Let’s look at what was required.

Read more »

NuGet and .NET Core

Saturday, October 28 2017 psake powershell

After my previous post on upgrading my project to compile with .NET Core, I found some unexpected issues compiling my NuGet package.

Read more »

The day my build broke

Saturday, November 04 2017 psake powershell

Recently, one of my build scripts failed with an odd error, claiming that the application wasn’t recognized. Given that the script had been working fine the previous day, this error was rather confusing.

Read more »

Tracking time

Saturday, November 11 2017 psake powershell

For diagnostic purposes, it can often be useful to know when specific build tasks started and how long they took to execute. This information can help you spot anomalies and resolve odd issues.

Read more »

Test Coverage History

Saturday, November 18 2017 psake powershell

On my previous post on code coverage, someone asked if the coverage report could highlight areas where coverage decreased. It turns out that ReportGenerator can do this, but there’s room for improvement.

Read more »

Bootstrapping a Psake build

Saturday, September 01 2018 psake powershell

The PowerShell based tool psake is a great way to orchestrate a build. It can also be used for many other kinds of orchestration. One of the trickiest parts is kicking off the process in the first place.

Read more »

Related posts

Checklists, Automation and Consistency  19 Jul 2015