Подтвердить что ты не робот

Форматирование вывода настраиваемого инструмента, чтобы я мог дважды щелкнуть по ошибке в Visual Studio и открыть файл

Я написал инструмент командной строки, который предварительно обрабатывает несколько файлов, а затем компилирует их с помощью CodeDom. Инструмент записывает уведомление об авторских правах и некоторый текст прогресса в стандартный вывод, а затем записывает любые ошибки на этапе компиляции, используя следующий формат:

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));
}

Затем он записывает количество ошибок, например "14 ошибок".

Это пример того, как ошибка появляется на консоли:

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)

Когда я запускаю это как настраиваемый инструмент в VS2008 (вызывая его в командной строке события пост-сборки одной из моих сборщиков проектов), ошибки отображаются в формате "отлично" в списке ошибок с правильным текстом в каждом столбце, Когда я просматриваю имя файла, открывается всплывающий путь. Строка и столбец отличаются от исходного файла из-за предварительной обработки, которая в порядке. Единственное, что выделяется, это то, что проект, указанный в списке, является тем, у которого есть событие после сборки.

Проблема заключается в том, что при двойном щелчке ошибки ничего не происходит. Я бы ожидал, что файл откроется в редакторе.

Я хорошо осведомлен о пространстве имен Microsoft.VisualStudio.Shell.Interop, но я думаю, что это должно быть возможно только путем записи стандартного вывода.

EDIT: я заметил некоторые моменты и сам решил:

  • FQP, который появляется при перелистывании имени файла, на самом деле не прав,
  • Я выводил путь относительно корня пути решения,
  • инструмент вызывается в проекте в другой папке,
  • и VS формирует путь относительно пути вызывающего проекта
4b9b3361

Ответ 1

Поскольку я выводил относительный путь в моем инструменте, Visual Studio формировал абсолютный путь к файлу, используя путь вызывающего проекта, а это означало, что сгенерированный абсолютный путь не существовал. Решением является просто вывод абсолютного пути к исходному файлу.

Ответ 2

Стандартный способ сделать это - реализовать ваш инструмент как MSBuild Task, тогда у вас будет доступ к объекту Log:

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

Это, например, работает интеграция жандармов /Visual Studio. Кроме того, это упрощает добавление вашего инструмента в файлы проекта (просто отбросьте задачу внутри <Target Name="AfterBuild">, и все готово).

Если вы не хотите этого делать, убедитесь, что результат вашего инструмента соответствует точно тем, что ожидает Visual Studio: http://blogs.msdn.com/b/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-error-messages-and-message-formats.aspx

Важным "gotcha" является то, что пути к файлам должны выводиться как абсолютные пути, в противном случае Visual Studio может неправильно их расширять.