C# “tlbexp.exe”的非确定性行为的原因？

我正在使用

tlbexp.exe

从C#项目生成一个类型库。该项目包含两个带有COM接口声明的文件，我们称之为F1和F2。F1和F2包含仅大小写不同的标识符（F1具有属性“Foo”，F2具有变量名“Foo”）。因此，我受到“MIDL更改生成的类型库中标识符的大小写”问题的影响（参见或）

现在有趣的是，

tlbexp.exe

有时生成正确的类型库，有时生成错误的类型库：

• 如果我在我的开发机器上的分支A上编译项目，那么类型库是正确的。这意味着

  tlbexp.exe

  已按F1、F2顺序查看文件
• 如果我在同一台机器上编译分支B上的项目，则类型库不正确

  tlbexp.exe

  已按F2、F1顺序查看文件
• 如果我在构建服务器上编译项目，那么类型库对于两个分支都是正确的
• 如果我在其他开发人员的机器上编译项目，我会得到与我自己的开发机器相同的结果（即，分支a的结果是OK，分支B的结果是fail）
• 分支A和分支B上的项目是相同的-我通过递归比较所有文件/文件夹来检查这一点

现在我的问题是：是什么导致了

tlbexp.exe

的这种奇怪的非决定性行为？请注意，我问这个问题是出于好奇——我已经通过将两个文件F1和F2合并为一个文件解决了我的类型库问题

如果这很重要：我有VisualStudio2010SP1，我的项目设置为使用.NET4

---

答案是编译顺序是不确定的。我觉得这很难相信——如果输入完全相同，构建工具完全相同，那么非确定性行为意味着构建工具制造商必须为其构建工具配备一个“随机生成器”，以确保每次的编译顺序都不相同。这不太可能吗？还是我忽略了什么

说到这里，我试图通过将MSBuild构建输出从“minimal”增加到“diagnostic”来验证编译顺序。查看构建输出，对于失败的构建，我看到一行如下所示：

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe [...] F1.cs F2.cs [...]

如您所见，文件以正确的顺序F1、F2显示。我将其与一个成功的构建进行了比较，

csc.exe

命令行完全相同。因此，似乎编译顺序不是问题所在

---

---

编辑：我知道

tlbexp.exe

可能不是根本原因，因此此问题的标题可能有点不充分。

我以前遇到过此问题，根据我的经验，最好不要重命名其中一个标识符。这很糟糕，但它会为您节省很多痛苦。编译器多线程可能会在没有任何人加入“随机生成器”的情况下导致不确定的构建行为。我不能说这里是否是这种情况，但这肯定是可能的。