В Visual Studio 2010 инкрементные сборки выполняются с помощью File Tracker (Microsoft.Build.Utilities.FileTracker). Похоже, что он отвечает за создание этих файлов *.1.tlog в промежуточном каталоге.

Я не мог найти ссылки на синтаксис этих файлов .tlog.
Они содержат список путей к файлам, которые читаются/записываются, когда трекер отслеживает выполнение какого-либо инструмента, чтобы проверить, какие файлы должны быть скомпилированы в инкрементной сборке. Однако эти файлы также содержат некоторые специальные символы, такие как "^" и "|".
Еще одна вещь, которую я заметил, это то, что эти файлы иногда редактируются из файлов целей Visual Studio. Например, в Microsoft.CppCommon.targets на целевом элементе CustomBuildStep я нашел следующую строку:

 <!-- Appended tlog to track custom build events -->
    <WriteLinesToFile File="$(IntDir)$(ProjectName).write.1.tlog" Lines="@(CustomBuildStep->'^%(Identity)');@(CustomBuildStep->MetaData('Outputs')->FullPath()->Distinct())"/>

Таким образом, это, вероятно, означает, что файл проекта зависит от выходов пользовательского шага сборки.

Мои вопросы:

Кто-нибудь знает ссылку для синтаксиса файла .tlog?
В каких случаях используется трекер-журнал, используемый в Visual Studio? Я знаю CL и, возможно, задачи Link, которые его используют, но, похоже, сама IDE Visual Studio использует его, чтобы решить, нужно ли вообще запускать msbuild для определенного проекта.

Спасибо

ИЗМЕНИТЬ

Другой намек:

CanonicalTrackedInputFiles Class является документом как "интерпретатор журналов файловой трассировки для журналов отслеживания .read. в канонической форме или тех, которые были внедрены (^), чтобы сделать их каноническими"
Когда у меня будет время, я буду копать в нее немного больше. Возможно, этот класс и другие под Microsoft.Build.Utilities могут использоваться, чтобы помочь нам работать с tlog файлами, а не напрямую работать с необработанными текстовыми файлами tlog,

Смотрите также: CanonicalTrackedOutputFiles Class, FlatTrackingData Class и, конечно, FileTracker Class.

Ответ 1

Этот материал, похоже, не документирован нигде, поэтому мне пришлось выяснить это на основе проб и ошибок и, посмотрев на пример файла targets/xml/props:

Причина, по которой шаг пользовательской сборки записывает в файл tlog вручную, заключается в том, что Build | Clean - и, вероятно, его коллега командной строки - сбрасывает файлы tlog, чтобы найти файлы, которые нужно удалить. Кажется, что все файлы, соответствующие *.write.tlog, или, возможно, *.1.write.tlog, в промежуточной папке, читают список имен файлов в каждом и удаляют имена файлов. Таким образом, если пользовательские шаги сборки знают, что представляют собой его выходы, они могут просто записывать их в файл tlog и взаимодействовать с Build | Clean таким образом.

(Вы можете попробовать это самостоятельно - создайте свой проект, создайте временные файлы, добавьте свой собственный файл tlog в промежуточную папку проекта, содержащую пути к временным файлам, затем выполните сборку "Очистить". Ваши временные файлы будут удалены вместе с обычными артефактами сборки.)

В файле tlog файл без префикса - это имя выходного файла. Эти файлы удаляются, когда вы создаете Build | Clean.

Файл с ^ перед этим комментарий, я думаю - возможно, очевидно, что Build | Clean не касается ни одного из них.

Что касается |, я видел его только в строках комментариев, используемых для разделения разных имен файлов. Я подозреваю, что это просто соглашение, а не какой-то специальный синтаксис, поскольку, если вы помещаете несколько выходных файлов в строку, разделенных |, Build | Clean не удаляет их.

Формат файла журнала File Tracker

ИЗМЕНИТЬ

Другой намек:

Ответ 1

Ответ 2