Formatting the output of a custom tool so I can double click an error in Visual Studio and the file opens

Question

I've written a command line tool that preprocesses a number of files then compiles them using CodeDom. The tool writes a copyright notice and some progress text to the standard output, then writes any errors from the compilation step using the following format:

foreach (var err in results.Errors) {
    // err is CompilerError
    var filename = "Path\To\input_file.xprt";
    Console.WriteLine(string.Format(
        "{0} ({1},{2}): {3}{4} ({5})",
        filename,
        err.Line,
        err.Column,
        err.IsWarning ? "" : "ERROR: ",
        err.ErrorText,
        err.ErrorNumber));
}

It then writes the number of errors, like "14 errors".

This is an example of how the error appears in the console:

Path\To\input_file.xrpt (73,28): ERROR: An object reference is required for the non-static field, method, or property 'Some.Object.get' (CS0120)

When I run this as a custom tool in VS2008 (by calling it in the post-build event command line of one of my project's assemblies), the errors appear nicely formatted in the Error List, with the correct text in each column. When I roll over the filename the fully qualified path pops up. The line and column are different to the source file because of the preprocessing which is fine. The only thing that stands out is that the Project given in the list is the one that has the post-build event.

The problem is that when I double click an error, nothing happens. I would have expected the file to open in the editor.

I'm vaugely aware of the Microsoft.VisualStudio.Shell.Interop namespace but I think it should be possible just by writing to the standard output.

EDIT: I noticed some points and solved this myself:

• the FQP that pops up when rolling over the filename wasn't actually correct,
• I was outputing a path relative to the solution root path,
• the tool is being called in a project in another folder,
• and VS is forming the path relative to the path of the calling project

Answer 1

Since I was outputting a relative path in my tool, Visual Studio was forming the absolute path to the file using the path of the calling project, which meant that the generated absolute path didn't exist. A solution is simply to output the absolute path to the source file.

Answer 2

Standard way to do this would be to implement your tool as a MSBuild Task, then you would have access to the Log object:

Log.LogError(subcategory, errorCode, helpKeyword, file, lineNumber, columnNumber,
    endLineNumber, endColumnNumber, message, messageArgs);

This is for example how Gendarme/Visual Studio integration works. Also, this make it easier to add your tool to project files (just drop a task inside <Target Name="AfterBuild"> and you're done).

If you don't want to do this, then make sure that your tool's output conforms exactly to what Visual Studio is expecting: http://blogs.msdn.com/b/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-error-messages-and-message-formats.aspx

An important "gotcha" is that file paths should be output as absolute paths, otherwise Visual Studio may expand them wrongly.