msbuild.exe 保持打开状态，锁定文件 [英] msbuild.exe staying open, locking files

问题描述

我使用 TeamCity，它反过来调用 msbuild (.NET 4).我有一个奇怪的问题，在构建完成后(它是否成功构建似乎并不重要)，msbuild.exe 保持打开状态，并锁定其中一个文件，这意味着每次 TeamCity 尝试清除其工作目录，失败，无法继续.

I use TeamCity which in turn invokes msbuild (.NET 4). I have a strange issue in that after a build is complete (and it doesn't seem to matter if it was a successful build or not), msbuild.exe stays open, and locks one of the files, which means every time TeamCity tries to clear its work directory, it fails, and can't continue.

这种情况几乎每次都会发生.

This happens almost every time.

我真的迷路了，所以我会尽量提供尽可能多的细节.

I'm really lost on this one, so I'll try to provide as much detail as possible.

• 服务器是 Intel Core i7、2 GB 内存、Windows Server 2008 标准 64 位 SP2.
• 在 TeamCity 中，msbuild runner 配置了 /m 命令行参数(意味着使用多个内核)
• 有问题的文件总是在路径 External ToolsTelerikTelerik.Reporting.Dll.(在类似的路径结构中，External Tools 目录中包含其他几个 .DLL 文件，这些文件永远不会导致此问题).目前这是 Telerik 报告的试用版，以防万一.
• 当问题发生时，任务管理器中总是列出几个msbuild.exe *32进程:我相信有7个.使用进程资源管理器，它们看起来都像顶级进程(没有父母).他们都使用 20-50MB 的内存和 0.0% 的 CPU.
• 如果我等待 1-3 分钟，msbuild.exe 进程会自行退出，然后 TeamCity 可以正确更新工作目录.
• 如果我手动终止 msbuild 进程，TeamCity 的更新将立即再次生效.
• 索引服务在 Windows 中已关闭(尽管前两点几乎证实是 msbuild.exe 导致了问题).
• Telerik.reporting.dll 没有特殊属性.唯一的 SVN 属性是 svn:mime-type = application/octet-stream

• Server is an Intel Core i7, 2 GB ram, with Windows Server 2008 standard 64-bit SP2.
• In TeamCity, the msbuild runner is configured with the /m command-line parameter (which means to use multiple cores)
• The file in question is ALWAYS the same external DLL that is referenced in one of the .NET projects, in the path External ToolsTelerikTelerik.Reporting.Dll. (There are several other .DLL files included in the External Tools dir in a similar path structure which never cause this problem). Currently this is with the trial version of Telerik reports, in case that makes any difference.
• When the issue happens, there are always several msbuild.exe *32 processes listed in Task manager: I believe there are 7. Using Process Explorer, they all look like top-level processes (no parents). They're all using from 20-50MB ram, and 0.0% CPU.
• If I wait 1-3 minutes, the msbuild.exe processes exit on their own, and TeamCity can then update the work directory properly.
• If I manually terminate the msbuild processes, TeamCity's update will work again immediately.
• Indexing services are turned off in Windows (though the prior two points pretty much confirm it's msbuild.exe causing the problem).
• There are no special properties on Telerik.reporting.dll. The only SVN property is svn:mime-type = application/octet-stream

以前有人遇到过这个吗?

Has anyone run across this before?

推荐答案

使用 msbuild 和 /nr:false.

简而言之:MSBuild 试图做很多事情来提高速度，尤其是并行构建.它将产生大量的节点".- 可以编译项目的单个 msbuild.exe 进程，并且由于进程需要一些时间来启动，在构建完成后，这些进程会挂起(默认情况下，我认为是 15 分钟)，所以如果你碰巧很快再次构建，这些节点可以重用"；并节省工艺设置成本.但是您可以通过使用上述命令行选项关闭 nodeReuse 来禁用该行为.

Briefly: MSBuild tries to do lots of things to be fast, especially with parallel builds. It will spawn lots of "nodes" - individual msbuild.exe processes that can compile projects, and since processes take a little time to spin up, after the build is done, these processes hang around (by default, for 15 minutes, I think), so that if you happen to build again soon, these nodes can be "reused" and save the process setup cost. But you can disable that behavior by turning off nodeReuse with the aforementioned command-line option.

另见:

• 并行构建后 MSBuild 和 ConHost 保留在内存中

MSBuild 命令行参考

不锁定自定义 MSBuild 任务 DLL 的并行构建

MultiProc MSBuild 中的节点重用

这篇关于msbuild.exe 保持打开状态，锁定文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！