为什么 MSBuild 将 .tlog 文件生成到 CMakeFiles/CompilerIdC 中，我该如何停止它？
Why is MSBuild generating .tlog files into CMakeFiles/CompilerIdC, and how do I make it stop?
我有一个 CMake 项目，我的一个构建是在 Visual Studio 上，使用 MSBuild，在 TeamCity 构建服务器上。
我看到的是 运行ning git clean -f -d -x 时频繁失败（TeamCity 在初始化构建时自行执行的步骤，作为源检查的一部分）。它失败的原因是因为 .tlog 文件正在生成到我的 CMake 构建文件夹中——进入 CMake 的内部 CompilerIdC 项目，CMake 使用它来识别本地 C 编译器。
什么是 .tlog 文件，是什么触发了它们的创建？我还没有找到这方面的文档。
我不明白为什么它们 在 CMake 的 运行 和构建已经完成之后出现。我特别不明白为什么在删除所有 CompilerIdC 的源文件和项目文件后超过十五分钟才创建它们。
详情
正在将文件生成到 ${CMAKE_BUILD_DIR}/CMakeFiles/3.5.2/CompilerIdC/Debug/CompilerIdC.tlog 中。它们都是 link-VCTIP.(read|write|delete).*.tlog.
的形式
这是在 git clean 失败并在 08:41 停止的构建的文件夹状态（截至 09:30）：
-rw-r--r-- 1 CI 197121 570 Jun 28 08:57 link-VCTIP.delete.1.tlog
-rw-r--r-- 1 CI 197121 1422 Jun 28 08:57 link-VCTIP.delete.26.tlog
-rw-r--r-- 1 CI 197121 7062 Jun 28 08:57 link-VCTIP.read.1.tlog
-rw-r--r-- 1 CI 197121 402 Jun 28 08:50 link-VCTIP.read.103.tlog
-rw-r--r-- 1 CI 197121 402 Jun 28 08:55 link-VCTIP.read.120.tlog
-rw-r--r-- 1 CI 197121 418 Jun 28 08:57 link-VCTIP.read.26.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.read.27.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.read.28.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.read.29.tlog
-rw-r--r-- 1 CI 197121 402 Jun 28 08:45 link-VCTIP.read.87.tlog
-rw-r--r-- 1 CI 197121 600 Jun 28 08:57 link-VCTIP.write.1.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.write.26.tlog
构建日志如下所示：
[08:39:58][VCS Root: MyVCS] [D:\TeamCity\buildAgent\worka2d5637a76fb3e]: "C:\Program Files\Git\bin\git.exe" clean -f -d -x
[08:41:26][VCS Root: MyVCS] warning: failed to remove build/Windows-x64-Release/: Directory not empty
[08:41:27]
[Updating sources] Failed to perform checkout on agent: '"C:\Program Files\Git\bin\git.exe" clean -f -d -x' command failed.
stdout: Removing Artifacts/x64/
<snip>
Removing build/Windows-x64-Release/CMakeFiles
<snip>
stderr: warning: failed to remove build/Windows-x64-Release/: Directory not empty
版本信息
我使用的工具是：
- MSBuild 14.0
- CMake 3.5.2
- TeamCity 专业版 9.1.7
什么是 .tlog 个文件？
它们由 MSBuild 的文件跟踪器输出，它包装 Visual C++ 构建可执行文件（例如 cl.exe 和 link.exe）以跟踪它写入和读取的文件。它将这些文件路径记录在中间目录的 .tlog 文件中，并依赖于这些文件路径来定义应如何构建增量构建。
（来源：Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build，作者 Sayed Hashimi 和 William Bartholomew。）
是什么触发了他们的创作？
对 MSBuild 的任何使用都可能触发 .tlog 个文件的创建或更新。
为什么这些文件出现得这么晚？
写入 .tlog 个文件的进程之一是 vctip.exe。 2018 年 3 月，Microsoft 工程师 Ian Bearman（VC++ 遥测所有者）explained:
This small application is a background process that runs during the build and allows the VC++ tools to communicate with the VS Telemetry Service (also known as VS Experience Improvement Program). The application stays running after a build in case another build is started immediately to help speed up compilation.
I understand that the current timeout (approaching something like 15 minutes) is way too long.
所以，答案是：即使在构建结束后，后台进程仍然存在，在这种情况下，即使所有相关文件都被删除，并继续尝试将遥测文件写入其目录。
我该如何解决这个问题？
Bearman 建议 two solutions:
- 升级Visual Studio.
Upcoming releases of Visual Studio (starting with VS 2017 15.7, now in preview) will shorten the time this stays running down to 15 seconds after the last build. Hopeful this will resolve any issues you have with this program staying running.
（我没有尝试过升级，所以我无法确认这是否解决了问题。我还感兴趣地注意到 an earlier bug report of very much the same issue, which was answered with a promise in March 2018 最近的更新已经解决了这个问题。）
- 手动杀
vctip.exe.
In the meantime, to workaround this problem feel free to manually kill vctip.exe at any time. You can use the Windows command taskkill /IM vctip.exe to stop it immediately. This is always safe to do without fear of data-loss or corruption.
在我自己的 TeamCity 特定案例中，在 MSBuild 完成后，这很容易作为额外的构建步骤添加到您的构建配置中 -- 运行 脚本：
taskkill /IM vctip.exe /f >nul 2>&1
请注意，此解决方案确实对您的构建系统做出了某些假设，例如它不是 运行 一次构建多个。并确保将其记录下来，因为稍后弄清楚它的来源将是一件令人头疼的事情...
这里的实际根本原因修复项可能是：
https://visualstudio.microsoft.com/team-services/support/build-troubleshooting-guidance/
MSBuild and /nodeReuse:false
If you invoke MSBuild during your build, make sure to pass the argument /nodeReuse:false (short form /nr:false). Otherwise MSBuild process(es) will remain running after the build completes. The process(es) remain for some time in anticipation of a potential subsequent build.
This feature of MSBuild can interfere with attempts to delete or move a directory – due to a conflict with the working directory of the MSBuild process(es).
The MSBuild and Visual Studio Build tasks already add /nr:false to the arguments passed to MSBuild. However, if you invoke MSBuild from your own script, then you would need to specify the argument.
？
（如果这里真的是正确的处理方式，那将是
比更精确的治疗
需要在随机时间随机杀死随机非拥有进程的不确定性解决方法）
请注意
如果这是根本原因，那么
这可能也需要在 CMake 生成器源代码（msbuild 调用 [ conditionally/intelligently]）中修复...
旁注：我考虑保持后台进程的机制 运行 - 喘息！ - 以相当终生不精确/不受控制的方式进行遥测（目录占用，...），而这据称是 precisely-controlled/-executed/-deterministic 构建处理，这是一个相当值得怀疑的[/冒犯] 事情。
我有一个 CMake 项目，我的一个构建是在 Visual Studio 上，使用 MSBuild，在 TeamCity 构建服务器上。
我看到的是 运行ning git clean -f -d -x 时频繁失败（TeamCity 在初始化构建时自行执行的步骤，作为源检查的一部分）。它失败的原因是因为 .tlog 文件正在生成到我的 CMake 构建文件夹中——进入 CMake 的内部 CompilerIdC 项目，CMake 使用它来识别本地 C 编译器。
什么是 .tlog 文件，是什么触发了它们的创建？我还没有找到这方面的文档。
我不明白为什么它们 在 CMake 的 运行 和构建已经完成之后出现。我特别不明白为什么在删除所有 CompilerIdC 的源文件和项目文件后超过十五分钟才创建它们。
详情
正在将文件生成到 ${CMAKE_BUILD_DIR}/CMakeFiles/3.5.2/CompilerIdC/Debug/CompilerIdC.tlog 中。它们都是 link-VCTIP.(read|write|delete).*.tlog.
这是在 git clean 失败并在 08:41 停止的构建的文件夹状态（截至 09:30）：
-rw-r--r-- 1 CI 197121 570 Jun 28 08:57 link-VCTIP.delete.1.tlog
-rw-r--r-- 1 CI 197121 1422 Jun 28 08:57 link-VCTIP.delete.26.tlog
-rw-r--r-- 1 CI 197121 7062 Jun 28 08:57 link-VCTIP.read.1.tlog
-rw-r--r-- 1 CI 197121 402 Jun 28 08:50 link-VCTIP.read.103.tlog
-rw-r--r-- 1 CI 197121 402 Jun 28 08:55 link-VCTIP.read.120.tlog
-rw-r--r-- 1 CI 197121 418 Jun 28 08:57 link-VCTIP.read.26.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.read.27.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.read.28.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.read.29.tlog
-rw-r--r-- 1 CI 197121 402 Jun 28 08:45 link-VCTIP.read.87.tlog
-rw-r--r-- 1 CI 197121 600 Jun 28 08:57 link-VCTIP.write.1.tlog
-rw-r--r-- 1 CI 197121 286 Jun 28 08:57 link-VCTIP.write.26.tlog
构建日志如下所示：
[08:39:58][VCS Root: MyVCS] [D:\TeamCity\buildAgent\worka2d5637a76fb3e]: "C:\Program Files\Git\bin\git.exe" clean -f -d -x
[08:41:26][VCS Root: MyVCS] warning: failed to remove build/Windows-x64-Release/: Directory not empty
[08:41:27]
[Updating sources] Failed to perform checkout on agent: '"C:\Program Files\Git\bin\git.exe" clean -f -d -x' command failed.
stdout: Removing Artifacts/x64/
<snip>
Removing build/Windows-x64-Release/CMakeFiles
<snip>
stderr: warning: failed to remove build/Windows-x64-Release/: Directory not empty
版本信息
我使用的工具是：
- MSBuild 14.0
- CMake 3.5.2
- TeamCity 专业版 9.1.7
什么是 .tlog 个文件？
它们由 MSBuild 的文件跟踪器输出，它包装 Visual C++ 构建可执行文件（例如 cl.exe 和 link.exe）以跟踪它写入和读取的文件。它将这些文件路径记录在中间目录的 .tlog 文件中，并依赖于这些文件路径来定义应如何构建增量构建。
（来源：Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build，作者 Sayed Hashimi 和 William Bartholomew。）
是什么触发了他们的创作？
对 MSBuild 的任何使用都可能触发 .tlog 个文件的创建或更新。
为什么这些文件出现得这么晚？
写入 .tlog 个文件的进程之一是 vctip.exe。 2018 年 3 月，Microsoft 工程师 Ian Bearman（VC++ 遥测所有者）explained:
This small application is a background process that runs during the build and allows the VC++ tools to communicate with the VS Telemetry Service (also known as VS Experience Improvement Program). The application stays running after a build in case another build is started immediately to help speed up compilation.
I understand that the current timeout (approaching something like 15 minutes) is way too long.
所以，答案是：即使在构建结束后，后台进程仍然存在，在这种情况下，即使所有相关文件都被删除，并继续尝试将遥测文件写入其目录。
我该如何解决这个问题？
Bearman 建议 two solutions:
- 升级Visual Studio.
Upcoming releases of Visual Studio (starting with VS 2017 15.7, now in preview) will shorten the time this stays running down to 15 seconds after the last build. Hopeful this will resolve any issues you have with this program staying running.
（我没有尝试过升级，所以我无法确认这是否解决了问题。我还感兴趣地注意到 an earlier bug report of very much the same issue, which was answered with a promise in March 2018 最近的更新已经解决了这个问题。）
- 手动杀
vctip.exe.
In the meantime, to workaround this problem feel free to manually kill vctip.exe at any time. You can use the Windows command
taskkill /IM vctip.exeto stop it immediately. This is always safe to do without fear of data-loss or corruption.
在我自己的 TeamCity 特定案例中，在 MSBuild 完成后，这很容易作为额外的构建步骤添加到您的构建配置中 -- 运行 脚本：
taskkill /IM vctip.exe /f >nul 2>&1
请注意，此解决方案确实对您的构建系统做出了某些假设，例如它不是 运行 一次构建多个。并确保将其记录下来，因为稍后弄清楚它的来源将是一件令人头疼的事情...
这里的实际根本原因修复项可能是：
https://visualstudio.microsoft.com/team-services/support/build-troubleshooting-guidance/
MSBuild and /nodeReuse:false
If you invoke MSBuild during your build, make sure to pass the argument /nodeReuse:false (short form /nr:false). Otherwise MSBuild process(es) will remain running after the build completes. The process(es) remain for some time in anticipation of a potential subsequent build.
This feature of MSBuild can interfere with attempts to delete or move a directory – due to a conflict with the working directory of the MSBuild process(es).
The MSBuild and Visual Studio Build tasks already add /nr:false to the arguments passed to MSBuild. However, if you invoke MSBuild from your own script, then you would need to specify the argument.
？ （如果这里真的是正确的处理方式，那将是 比更精确的治疗 需要在随机时间随机杀死随机非拥有进程的不确定性解决方法）
请注意 如果这是根本原因，那么 这可能也需要在 CMake 生成器源代码（msbuild 调用 [ conditionally/intelligently]）中修复...
旁注：我考虑保持后台进程的机制 运行 - 喘息！ - 以相当终生不精确/不受控制的方式进行遥测（目录占用，...），而这据称是 precisely-controlled/-executed/-deterministic 构建处理，这是一个相当值得怀疑的[/冒犯] 事情。