导致`tlbexp.exe`的非确定性行为？

Question

我正在使用tlbexp.exe从C＃项目生成类型库。该项目包含2个文件 - 让我们称之为F1和F2 - 使用COM接口声明。 F1和F2包含仅在大小写不同的标识符（F1具有属性“Foo”，F2具有变量名称“foo”）。因此，我受“MIDL更改生成的类型库中的标识符的情况”问题的影响（参见this MSDN article，或this SO question）。

现在有趣的是，tlbexp.exe有时会生成一个正确的类型库，有时它会生成一个不正确的类型库：

• 如果我在开发机器上的分支A上编译项目，那么类型库是正确的。这意味着tlbexp.exe已经按F1，F2
的顺序看到了这些文件
• 如果我在分支B上编译项目，则在同一台机器上，类型库不正确。 tlbexp.exe已按F2，F1。
的顺序查看了这些文件
• 如果我在构建服务器上编译项目，那么两个分支的类型库都是正确的！
• 如果我在同事开发者的机器上编译项目，我会得到与我自己的开发机器相同的结果（即分支A的确定，分支B的失败）
• 分支A和B上的项目是相同的 - 我通过递归 - 比较所有文件/文件夹来检查它。

现在我的问题是：tlbexp.exe导致这种奇怪和非威慑行为的原因是什么？请注意，我出于好奇而问这个问题 - 我已经通过将两个文件F1和F2合并为一个来解决我的类型库问题。

如果它很重要：我有Visual Studio 2010 SP1，我的项目设置为使用.NET 4.

---

this SO question的答案声称这是非确定性的编译顺序。我发现这很难相信 - 鉴于完全相同的输入和完全相同的构建工具，非确定性行为意味着构建工具制造商必须为其构建工具配备“随机生成器”，以确保编译顺序不是每次都一样。这不太可能吗？或者我忽略了什么？

说了这么多，我试图通过将MSBuild构建输出从“minimal”增加到“diagnostic”来验证编译顺序。看一下构建输出，我看到这样一行代表一个失败的构建：

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

如您所见，文件以正确的顺序显示F1，F2。我将其与成功构建进行了比较，csc.exe命令行完全相同。所以看起来好像编译顺序不是问题。

---

编辑：我理解tlbexp.exe可能不是根本原因，所以这个问题的标题可能有点不合适。