GenerateResource/CoreResGen突然花费了将近30倍的时间

ResXtoResources.exe 占用大量CPU一段时间。我终于能够使用MSBuild的“诊断”输出设置获取一些数据,并将该输出与几个月前在分支中看到的结果进行比较。最引人注目的是给出时间安排的最后一行。之前:

Target Performance Summary:
[..]
     1395 ms  CoreResGen                                 1 calls
     1930 ms  CompileLicxFiles                           1 calls
     2135 ms  GenerateApplicationManifest                1 calls
     2844 ms  CoreCompile                                1 calls

Task Performance Summary:
[..]
     1391 ms  GenerateResource                           1 calls
     1929 ms  LC                                         1 calls
     2134 ms  GenerateApplicationManifest                1 calls
     2843 ms  Vbc                                        1 calls

Build succeeded.

Time Elapsed 00:00:09.50
========== Rebuild All: 5 succeeded, 0 failed, 0 skipped ==========

Target Performance Summary:
     1348 ms  CompileLicxFiles                           1 calls
     1747 ms  GenerateApplicationManifest                1 calls
     2595 ms  CoreCompile                                1 calls
    39575 ms  CoreResGen                                 1 calls

Task Performance Summary:
     1347 ms  LC                                         1 calls
     1745 ms  GenerateApplicationManifest                1 calls
     2593 ms  Vbc                                        1 calls
    39570 ms  GenerateResource                           1 calls

Build succeeded.

Time Elapsed 00:00:47.34
========== Rebuild All: 5 succeeded, 0 failed, 0 skipped ==========

这两个项目都是在同一个系统上以相同的设置编译的。可以肯定的是,我们已经做了很多更改,但是没有任何数量级的更改可以证明这样的时间更改是合理的(而且只针对这一项任务!)。我假设资源生成被某个循环引用、丢失的引用等卡住了。但是,我一直找不到任何有用的方法来跟踪这样的问题,直到我假设只有一个资源文件。

除了查看成千上万的签入或者从项目中临时删除一些表单(以及它们的资源文件),我还能做些什么来解决这个问题吗?我似乎找不到每个资源文件的计时。

我创建了一个新的空项目 .resx 文件就位。

• 这个问题在.NET4.0中是不可复制的:编译完全相同的测试项目只需不到一秒钟。
• 只要我还添加了原始项目中的一个表单,这个问题就可以在.NET2.0中重现;显然,否则它将无法“正确”编译资源。
• .resx文件