16

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.

SuperBiasedMan
  • 9,814
  • 10
  • 45
  • 73
Aren
  • 54,668
  • 9
  • 68
  • 101

2 Answers2

19

To create an error, warning, or message that will appear in the Error List window, simply log a message to stdout or stderr in the following format from a script initiated by a pre- or post-build event. Please comment or edit if there is an official spec; this is only what I was able to deduce by trial-and-error and by watching the output of MSBuild. Square brackets denote "optional":

FilePath[(LineNumber[,ColumnNumber])]: MessageType[ MessageCode]: Description

As an example:

E:\Projects\SampleProject\Program.cs(18,5): error CS1519: Invalid token '}' in class, struct, or interface member declaration

For more examples, see the Output window for any error/warning/message that may occur when you run a build in Visual Studio.

Roy Tinker
  • 10,044
  • 4
  • 41
  • 58
  • 4
    This was very helpful. Thanks for taking the time to figure it out. Just made my post build steps that much better. – Pete Magsig Aug 02 '13 at 16:37
  • [Here's something resembling an official spec](http://blogs.msdn.com/b/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-error-messages-and-message-formats.aspx), from the (probably-now-deleted) [answer](http://stackoverflow.com/a/35289349/3614835) by [Catalin Sindelaru](https://stackoverflow.com/users/5747703/catalin-sindelaru). – Jeffrey Bosboom Apr 18 '16 at 01:34
13

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 MachineTM 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.

Screenshot

kbrimington
  • 25,142
  • 5
  • 62
  • 74
  • I already have it displaying info to the build output. What I need is for the compile operation to FAIL when there's an error. And if possible have the message as to why it failed end up in the **Error List** – Aren Sep 13 '10 at 21:36
  • @Aren - Thanks for the response. I've updated the post with something that should help get the desired effect. – kbrimington Sep 13 '10 at 22:08
  • @kbrimington - No ideas on how to get the message to show up eh? – Aren Sep 13 '10 at 22:30
  • @Aren - You might get some mileage from running the PowerShell runtime within a build macro or a custom MSBuild task, but I'm not sure how to suggest you get started. For starters, try these resources: for macros - http://stackoverflow.com/questions/841725/run-visual-studio-2008-macro-on-pre-build-event, and for MSBuild tasks - http://bartdesmet.net/blogs/bart/archive/2008/02/15/the-custom-msbuild-task-cookbook.aspx. Good luck! – kbrimington Sep 14 '10 at 02:08
  • 1
    Technically `exit` is not an alias but a keyword; however the effect is the same as `Exit-PSSession`. – Keith Hill Sep 14 '10 at 03:05
  • @Keith - I think you're right. I was thrown off by `get-help exit` returning help pages on `Exit-PSSession`. Thanks. – kbrimington Sep 14 '10 at 04:27
  • @kbrimington - yeah noticed that too - a bit weird but wouldn't be the first weird thing I've found in the docs. :-) – Keith Hill Sep 14 '10 at 05:16
  • @kbrimington - Wow, thank you very much for taking the time to go this in-depth with my question, I'd give you +50 if I could :o – Aren Sep 14 '10 at 16:05