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.
The output from our current build script isn’t too bad to read, but there is room for improvement.
When the build happens, MSBuild outputs a lot of detail about what’s going on. Unfortunately, this output is at exactly the wrong level of detail to be useful to us.
From the viewpoint of seeing what is going on with our build, there’s far too much output; it swamps everything else with a flood of messaging. But from the viewpoint of working out what went wrong with our build, it’s far too little output.
Fortunately, MSBuild has all the options we need to get the output we want. We’ll reduce the output on the console to a minimal level while sending detailed logging into a file for later reference if needed.
(The options are wrapped for readability; if you’re trying this out for yourself, they all need to be on the same line.)
Note that we’re keeping things tidy, by writing the log file into a separate folder that’s used for build outputs. Imaginatively, we’ll call this
build - but we need to ensure that it exists when we need it.
To define the path to this folder, add a
properties block right at the top of the file:
$baseDir as the folder in which the our
build.ps1 file is found, and then defines
$buildDir relative to that point.
Ensuring the folder always exists when we want it is handled by a simple task:
Now we get this output when we run the build script:
As one last improvement, Psake lets us redefine the function
formatTaskName to change the way that task names are shown. Here’s an example that displays task names in the same way the Build Time Report is shown at the end.
We now get this output:
With these changes, our script has a high level of transparency - it is quite easy to see what our build script has done and where errors (if any) have taken place.