MSBuild WTF: “The error was:”

15 November 2006

Here’s a fun one for anyone who uses msbuild (at least, v2.0.50727). Create a project file like this:

<Project DefaultTargets="Foo" xmlns="">
  <Target Name="Foo">
        <Exec Command = "echo Hello!" />

From a command prompt, run the project; you will get a the effect you would expect.

Now replace the word “Hello” with “The error was: something random”. Run it again.

C:\\Dev\\Resolver>msbuild foo.proj
Microsoft (R) Build Engine Version 2.0.50727.42
[Microsoft .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation 2005. All rights reserved.

Build started 15/11/2006 17:50:22.
Project "C:\\Dev\\Resolver\\foo.proj" (default targets):

Target Foo:
    echo The error was: something random
    EXEC : The error was: something random
    C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
Done building target "Foo" in project "foo.proj" -- FAILED.

Done building project "foo.proj" -- FAILED.

EXEC : The error was:
C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:00.09


Fuzzyman and I bumped into this one at work today; our continuous integration server, which watches our Subversion repository and checks out, builds, and tests any code changes it sees, had reported a failure despite the fact that none of the tests had failed. It turned out that one test was quite innocently printing out the text “The error was: ” followed by some logging information; it wasn’t an error at all. As far as I can tell, the statement that the echo command exited with code -1 is absolute nonsense.

This behaviour is not documented anywhere that we were able to find; I can only assume it was added for some specific purpose in the context of Visual Studio…

4 thoughts on “MSBuild WTF: “The error was:”

  1. damjan

    Maybe the problem is with that colon (:). It has special meaning in windows.

  2. giles Post author

    I don’t think so – if you echo “Error:” then the problem doesn’t show up.

  3. Faisal Mohamood

    This is because Exec will parse the output produced by whatever you are running to interpret error messages that are in a specific format. See my blog post here:

    While this comes in handy to populate the error list in Visual Studio, that is not the primary reason – many tools use this error format today.

    In order to help you solve the issue, we are goin to make the “regex” used for specifying error formats extensible so that you can specify your own regular expression that can indicate what error format the Exec invocation should actually consider as an error. We hope for this feature to be available in Visual Studio / MSBuild Orcas.

    Faisal Mohamood | Program Manager | Visual Studio

  4. Giles


    Now that’s what I call customer service! :-) I wish I’d found a better ‘net search term and had been able to pick up this aspect of the msbuild command before posting irately… Should I assume, then, that “x error y: z” will always trigger this behaviour? Also – is the full regex documented anywhere online? I couldn’t quite be sure I understood the diagram on your blog.

    One further question – I am sure that while you were implementing this feature, you spent time deciding how to balance the Exec invocation’s returned error number against the apparent errors noted through matches to this regex – that is, whether a tool that returned 0, theoretically signalling success, but also printed out what appeared to be an error message, should be regarded to have failed or not. I come from a Unix-y background, and it seems wrong to me to not have the zero error code, meaning no error, “trump” what appears to be an error message. Obviously you and your team feel differently; I’d be very interested in knowing what the considerations that pointed you in that direction where. Have you posted – or do you intend to post – anything along those lines?



Comments are closed.