Skip to content

Instantly share code, notes, and snippets.

@sayedihashimi
Last active May 13, 2024 20:38
Show Gist options
  • Save sayedihashimi/2f449a1c38f62cf0b200920befe2e6a4 to your computer and use it in GitHub Desktop.
Save sayedihashimi/2f449a1c38f62cf0b200920befe2e6a4 to your computer and use it in GitHub Desktop.
MSBuild and Visual Studio Known Error Message Formats

MSBuild and Visual Studio Known Error Message Formats

When a tool is executed that outputs some text, MSBuild will examine the text for errors and warnings. Many tools use a known format to report these messages. By default, MSBuild will examine the text and report errors and/or warnings based on the output. This behavior can be changed or disabled by using these parameters on the Exec task: IgnoreStandardErrorWarningFormat, CustomErrorRegularExpression, and CustomWarningRegularExpression.

NOTE: If you do decide to use your own regular expression to detect error and warnings, then you should know that MSBuild will look at the result one line at a time. Even if your custom regex would match something across multiple lines, it will not behave that way because of how MSBuild processes that text.

Take a look at the following four messages, which are all properly formatted and will be recognized by MSBuild and Microsoft Visual Studio

Main.cs(17,20): warning CS0168: The variable 'foo' is declared but never used
C:\dir1\foo.resx(2) : error BC30188: Declaration expected.
cl : Command line warning D4024 : unrecognized source file type 'foo.cs', object . . .
error CS0006: Metadata file 'System.dll' could not be found.

These messages conform to the special five-part format shown in Figure 7-6. The order of these parts is important and should not change.

msbuild error format image

Now we will describe each of the components of this format:

  • Origin (Required) Origin can be blank. If present, the origin is usually a tool name, such as “cl” in one of the examples. But it could also be a file name, such as “Main.cs,” shown in another example. If it is a file name, then it must be an absolute or a relative file name, followed by an optional parenthesized line/column information in one of the following forms:
(line) or (line-line) or (line-col) or (line,col-col) or (line,col,line,col)

Lines and columns start at 1 in a file; that is, the beginning of a file is 1, and the leftmost column is 1. If the Origin is a tool name, then it must not change based on locale; that is, it needs to be locale-neutral.

  • Subcategory (Optional) Subcategory is used to classify the category itself further; it should not be localized.

  • Category (Required) Category must be either “error” or “warning”. Case does not matter. As with origin, category must not be localized.

  • Code (Required) Code identifies an application-specific error code/warning code. Code must not be localized and it must not contain spaces.

  • Text User-friendly text that explains the error, and it must be localized if you cater to multiple locales.

When MSBuild calls command-line tools (for instance, csc.exe or vbc.exe), it looks at the output emitted by the tool to the standard out and standard error streams. Any lines that match the error format that I just described will be treated specially; that is, lines that are recognized as errors or warnings will be turned into build errors and warnings, respectively. To see the real benefit of this, you have to be building from within Visual Studio. Because MSBuild treats these messages specially, they get logged as first-class warnings and errors in the Visual Studio task list. If the Origin specifies line/column information, then double-clicking the message will take you to the source of the error in the offending file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment