Question

I’ve got a nice power-shell driven post-build script that does some magic mumbo-jumbo for pulling all our plugins into the correct location after they’re compiled and sorting out thier dependencies with the master-project of the solution.

My problem is, occasionally when I do something stupid, I can end up in a state where my script can’t execute it’s operation correctly, and throws an exception in powershell with the details of what went wrong.

Is there a way to get these exceptions to pull up to the Visual Studio Error window so that when my post-build fails, vstudio gets a failure notification and nicely formats it in the window alongside all the other warnings/errors?

Edit: This is a clarification to what I’m ideally looking for.

removed dead ImageShack link

Note: If you’ve landed here looking for how to make custom error messages show up in Visual Studio (when you have control of the error messages) you can see Roy Tinker’s Answer to learn how to tailor your messages to show up. If you’re interested in catching unexpected errors you can’t control, or finding a more complete solution please see the accepted answer.

Answer 1

Here are two approaches for interrupting the build when a PowerShell script errors.

Use exit() to terminate the PowerShell process

To return a status code from the script which, if non-zero, will show up in the error list, use the following:

exit(45) # or any other non-zero number, for that matter.

This doesn’t precisely get the error text onto your error list, but it does terminate the script and get a little something in your error list to indicate which pre- or post-build command failed.

Use a custom MSBuild task to execute the PowerShell script

I spent a little time working out the details of executing a PowerShell script within an MSBuild task. I have a full article with sample code on my blog. Do check it out, as it includes more discussion, and some explanation of how to handle the sample projects. It’s probably not a complete or perfect solution, but I got it Working on My Machine^TM with a very simple script.

This approach provides line and column precision when reporting PowerShell errors, and even supports the double-click-takes-me-to-the-file behavior we’re accustomed to in Visual Studio. If it’s lacking, I’m sure you’ll be able to extend it to meet your needs. Also, depending on your version of Visual Studio, you may need to massage details like assembly reference versions.

First off, build a custom MSBuild Task in a class library project. The library should reference the following assemblies for MSBuild and PowerShell integration. (Note that this example requires PowerShell 2.0.)

• Microsoft.Build.Framework (GAC)
• Microsoft.Build.Utilities.v3.5 (GAC)
• System.Management.Automation (from C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0)

Build a task class, and expose a property to specify the path to the PowerShell script, like so:

using System.IO;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

public class PsBuildTask : Task
{
    [Required]
    public string ScriptPath { get; set; }

    public override bool Execute()
    {
        // ...
    }
}

Within the Execute() method, start the PowerShell run time, execute the script, and collect errors. Use the Log property to log the errors. When finished, close the runspace and return true if the script logged no errors.

// create Powershell runspace
Runspace runspace = RunspaceFactory.CreateRunspace();
runspace.Open();

// create a pipeline and feed it the script text
Pipeline pipeline = runspace.CreatePipeline();
pipeline.Commands.AddScript(". " + ScriptPath);

// execute the script and extract errors
pipeline.Invoke();
var errors = pipeline.Error;

// log an MSBuild error for each error.
foreach (PSObject error in errors.Read(errors.Count))
{
    var invocationInfo = ((ErrorRecord)(error.BaseObject)).InvocationInfo;
    Log.LogError(
        "Script",
        string.Empty,
        string.Empty,
        new FileInfo(ScriptPath).FullName,
        invocationInfo.ScriptLineNumber,
        invocationInfo.OffsetInLine,
        0,
        0,
        error.ToString());
}

// close the runspace
runspace.Close();

return !Log.HasLoggedErrors;

And that’s it. With this assembly in hand, we can configure another project to consume the MSBuild task.

Consider, for example, a C#-based class library project (.csproj). Integrating the task in a post build event requires just a few things.

First, register the task just inside the <Project> node of the .csproj file like so:

<UsingTask TaskName="PsBuildTask"
           AssemblyFile="..\Noc.PsBuild\bin\Debug\Noc.PsBuild.dll" />

TaskName should be the name of the task class, though it would seem the namespace is not required. AssemblyFile is an absolute path to the custom MSBuild task assembly, or relative path with respect to the .csproj file. For assemblies in the GAC, you can use the AssemblyName attribute instead.

Once registered, the task can be used within pre- and post-build events. Configure a build event within the <Project> element of the .csproj file like so:

<Target Name="AfterBuild">
    <PsBuildTask ScriptPath=".\script.ps1" />
</Target>

And that’s it. When Visual Studio compiles the project, it loads the custom assembly and task object and executes the task. Errors raised by the pipeline are retrieved and reported.