Visual Studio：构建顺序随机？

Question

我可以帮助您进行翻译。以下是您需要翻译的内容：

我有一个包含239个项目的解决方案。我目前遇到了以下问题：

当我对该解决方案执行“重新生成全部(rebuild all)”操作时，在进行完整的清理（删除输出目录）后：

17>------ Rebuild All started: Project: AAA, Configuration: Debug x86 ------
18>------ Rebuild All started: Project: BBB, Configuration: Debug x86 ------
18>CSC : error CS0006: Metadata file 'E:\Dev\Trunk\Debug\x86\AAA.dll' could not be found
17>  XmsCommon -> E:\Dev\Trunk\Debug\x86\AAA.dll

我了解以下内容：

• Visual Studio正在多线程编译（在我的情况下，每次同时编译4个程序集）
• 我没有明确指定“项目依赖项”（右键单击解决方案-〉项目依赖项）

我不理解以下内容：

• 在这个例子中，AAA是BBB的一个引用项目，对我来说，它是一种隐含的依赖关系，如何能够在确保正确构建AAA之前正确构建BBB？
• 对于包含239个项目的解决方案，我们应该如何管理此问题？要确保不将任何引用指向错误的项目已经足够困难，如果我们总是必须确保构建顺序，那么就变得复杂了。

一个注释：我不知道是否由于最近的更改（项目/visual studio/...），因为我已经在这个解决方案上工作了2年，这是我第一次反复遇到这个问题。

所以问题是：

1. 有没有办法处理这个问题，而不必在解决方案中指示每个项目依赖项？
2. 如果没有，我们应该怎么做？

编辑 在评论后，这里有一些其他信息:

• AAA或BBB中没有编译错误，除了找不到引用项
• 我们引用项目而不是dll（在我遇到错误的特定情况下进行了检查）

在BBB.csproj中，我有以下引用：

<ProjectReference Include="..\..\..\..\SomeOtherFolder\AAA\AAA.csproj">
  <Project>{6241076B-05B3-4D5D-AFA9-46D41E1CEC3A}</Project>
  <Name>AAA</Name>
  <Private>False</Private>
</ProjectReference>

编辑2

我不知道这是否直接相关，但在检查项目依赖关系时，我发现BBB依赖于CCC（但没有指定AAA）。我想知道是否有一个依赖关系指定，它基本上会忽略来自引用的所有信息？如果我尝试删除CCC依赖项，我会收到以下消息： 此依赖项是由项目系统添加的，无法移除

编辑3

我做了一个有趣的发现：实际上，我在编辑2中遇到的错误是因为在创建两个项目之间的引用时添加了此依赖项。

由于某种未知原因，似乎此依赖项未为一个引用创建。如果我删除项目引用，然后再次将引用添加到同一项目中，则现在具有此依赖关系（我无法删除）。 我找不到存储此“依赖项”的位置。 如何“修复”此解决方案？

- J4N

---

BBB 是在提到 AAA 的项目还是 AAA 的输出程序集？ - James Thorpe

也许 AAA 存在错误？AAA 单独构建是否正确？ - spender

它们是项目引用吗？还是只是引用了dll文件？如果是dll文件的引用：编译器无法解析这些内容；对于项目引用：它应该是能够解析的。 - Marc Gravell

我们总是引用项目（如果不是这样，会出现错误，但我不确定如何检查？在 Visual Studio 中，我们如何知道是引用项目还是 DLL？）解决方案上没有错误。 - J4N

请确认以下内容：在csproj文件中，是<ProjectReference>还是<Reference>？ - Marc Gravell

Answer 1

从您的帖子中，您说：“我没有明确地指定“项目依赖项””。这意味着您所有的引用都是编译后的DLL文件，而不是项目本身。

我曾经见过很多团队采用这种方法，因为VS加载如此多的项目引用速度非常缓慢，尤其对于具有239个项目的大型解决方案。

一般采取以下方法来解决：

1. 对于主要解决方案中的每个子区域，例如实体、DAL、逻辑、服务等，使用多个解决方案。

2. 将DLL文件（不推荐，但我见过）检入源代码中以用于更快的构建。一旦您更改了某个代码区域，就必须负责替换该DLL文件。

3. 配置“项目依赖项”设置，以便按正确的顺序进行构建。

4. 处理项目引用的性能问题（速度较慢，但可以确保构建顺序）。

一个只有239个项目的单一解决方案似乎违反了将开发分成较小模块的原则，但这并不总是您的决定...

- Martin Noreke

---

抱歉，也许我的句子有些令人困惑（对非英语人士而言:(）。我的意思是我们没有明确设置任何引用。但在进行了一些测试后（请参见编辑3），我发现由于项目引用（而且我100%确定它是项目引用而不是dll引用），某些依赖项是存在的。但是有些则不存在。我检查过了，我的一些同事在使用相同的工作区时，他们具有完全相同的文件，却拥有依赖项。 - J4N

Answer 2

经过一番调查，我找到了问题所在：

实际上，在将一个项目引用到另一个项目时，Visual Studio 应该自动添加这些项目之间的依赖关系。只需添加一个项目引用即可轻松看到。此外，似乎这些“依赖项”无法被移除（请参见我的第二次编辑）。

因此，我提出的问题是如何使一些项目具有引用但不具有某些项目的依赖项？

我检查了我的引用（至少在某些情况下我发现它并不起作用），它们是项目引用而不是 dll。

我的一些同事使用完全相同的代码（没有更改），却没有遇到这个问题，并且在 Visual Studio 中显示了依赖项。

因此，最终我删除了解决方案文件附近的 *.sdf 文件（在关闭 Visual Studio 后）。重新打开后，Visual Studio 重新计算了所有依赖项。现在，当我们重建时，一切都直接成功了。

我不确定为什么会出现这种情况，可能是因为我有一些时间没有关闭 Visual Studio，导致出现了某些损坏。

- J4N

Answer 3

我曾在一个较小但高度相互依赖的解决方案中遇到过这个问题。我们通过将最大并行项目构建数量降低，直到它可预测地成功来解决了这个问题。工具-->选项-->项目和解决方案-->构建和运行。

- AWinkle

---

我测试了只有一个并行项目来构建。 - J4N

Answer 4

我知道这不是一个解决方案，但如果您使用依赖注入技术（如MEF或Unity），您可以将编译依赖项转换为运行时依赖项。

在这种情况下，您的项目具有有限的依赖关系（接口，容器）。

但是，我必须说，这些技术会带来一些副作用-例如“伪随机”初始化等...

- sac1

---

我们并不为我们使用的每个对象（如业务数据）都提供接口。我喜欢依赖注入，但你的回答有点离题。 - J4N

是的，你说得对，正如我所写的那样，这不是一个解决方案。我们的产品有超过2k个项目，你必须将它们分开... - sac1