Visual Studio: 构建顺序随机？
Visual Studio: Build order random?
我有一个包含 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 个程序集）
- 我没有明确 "Project Dependency" 指定（右键单击解决方案 -> 项目依赖项）
我不明白的地方
- 在这个例子中AAA是BBB的引用项目，对我来说，它是一个隐式依赖，在不确定AAA是否已经正确构建的情况下如何正确构建BBB？
- 我们应该如何管理这个包含 239 个项目的解决方案？确保我们不引用错误的项目已经很困难了，所以如果我们总是要确保构建顺序，那就变得很复杂了。
一个注意事项：我不知道这是不是由于最近的变化（project/visual 工作室/...），因为我花了 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 依赖项，我会收到一条消息：
This dependency was added by the project system and cannot be removed
编辑 3
我有一个有趣的发现：事实上，我在 EDIT 2 中的错误是因为在创建两个项目之间的引用时添加了此依赖项。
由于未知原因，似乎没有为此处的一个引用创建此依赖项。如果我删除项目引用，然后再次将引用添加到同一个项目，我现在有了这个依赖项（我无法删除）。
我找不到这个“依赖项”的存储位置。
知道如何 "fix" 这个解决方案吗？
从你的 post 你说
"I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)" 这意味着您所有的引用都是对已编译的 DLL，而不是项目。
由于 VS 加载那么多项目引用的速度很慢，我已经多次看到具有大型解决方案（您有 239 个项目）的团队使用这种方法。
我见过的解决方法是：
- 主要解决方案的每个子区域的多个解决方案，例如实体、DAL、逻辑、服务等
- 将 DLL（不推荐，但我见过）签入源代码以用于更快的构建。更改代码区域后，您有责任替换 DLL。
- 配置项目依赖项设置，以便构建按正确顺序完成。
- 处理项目引用的性能（缓慢，但确保构建顺序
包含 239 个项目的单一解决方案似乎违背了将您的开发划分为更小模块的原则，但这并不总是您的决定...
我在一个较小但高度相互依赖的解决方案中看到了这个问题。我们通过减少并行项目构建的最大数量来解决这个问题，直到它可预测地成功。工具 --> 选项 --> 项目和解决方案 --> 构建和 运行.
经过一番调查，我发现了问题所在：
事实上 Visual Studio 应该在将一个项目引用到项目中时自动添加项目之间的依赖关系。只需添加一个项目参考，我就可以很容易地看到这一点。此外，似乎无法删除那些 "dependencies" （请参阅我的编辑 2）。
所以我问的问题是如何让一些项目被引用，而一些项目没有依赖性？
我检查了我的引用（至少在某些情况下我看到它不起作用）并且它们是项目引用而不是 dll。
我的一些同事使用完全相同的代码（获取最新版本的代码而无需更改）没有遇到此问题，并且在 Visual studio 中显示了依赖项。
所以我最后删除了解决方案文件附近的 *.sdf 文件（在关闭 visual studio 之后）。我重新打开和 tadaa，所有依赖项都已由 visual studio 重新计算。现在我rebuild，直接一切成功。
我不确定为什么会这样，我有一些时间来消磨时间 visual studio，也许那时有些东西被破坏了。
我知道这不是解决方案，但如果您使用依赖注入技术（如 MEF 或 Unity），您可以将编译依赖项转换为运行时依赖项。
在这种情况下，您的项目具有有限的依赖项（接口、容器）。
但我不得不说，这些技术有一些副作用 - 比如 'pseudo random' 初始化等等...
我有一个包含 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 个程序集）
- 我没有明确 "Project Dependency" 指定（右键单击解决方案 -> 项目依赖项）
我不明白的地方
- 在这个例子中AAA是BBB的引用项目，对我来说，它是一个隐式依赖，在不确定AAA是否已经正确构建的情况下如何正确构建BBB？
- 我们应该如何管理这个包含 239 个项目的解决方案？确保我们不引用错误的项目已经很困难了，所以如果我们总是要确保构建顺序，那就变得很复杂了。
一个注意事项：我不知道这是不是由于最近的变化（project/visual 工作室/...），因为我花了 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 依赖项，我会收到一条消息：
This dependency was added by the project system and cannot be removed
编辑 3
我有一个有趣的发现：事实上，我在 EDIT 2 中的错误是因为在创建两个项目之间的引用时添加了此依赖项。
由于未知原因，似乎没有为此处的一个引用创建此依赖项。如果我删除项目引用，然后再次将引用添加到同一个项目，我现在有了这个依赖项（我无法删除）。 我找不到这个“依赖项”的存储位置。 知道如何 "fix" 这个解决方案吗？
从你的 post 你说
"I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)" 这意味着您所有的引用都是对已编译的 DLL，而不是项目。
由于 VS 加载那么多项目引用的速度很慢，我已经多次看到具有大型解决方案（您有 239 个项目）的团队使用这种方法。
我见过的解决方法是：
- 主要解决方案的每个子区域的多个解决方案，例如实体、DAL、逻辑、服务等
- 将 DLL（不推荐，但我见过）签入源代码以用于更快的构建。更改代码区域后，您有责任替换 DLL。
- 配置项目依赖项设置，以便构建按正确顺序完成。
- 处理项目引用的性能（缓慢，但确保构建顺序
包含 239 个项目的单一解决方案似乎违背了将您的开发划分为更小模块的原则，但这并不总是您的决定...
我在一个较小但高度相互依赖的解决方案中看到了这个问题。我们通过减少并行项目构建的最大数量来解决这个问题，直到它可预测地成功。工具 --> 选项 --> 项目和解决方案 --> 构建和 运行.
经过一番调查，我发现了问题所在：
事实上 Visual Studio 应该在将一个项目引用到项目中时自动添加项目之间的依赖关系。只需添加一个项目参考，我就可以很容易地看到这一点。此外，似乎无法删除那些 "dependencies" （请参阅我的编辑 2）。
所以我问的问题是如何让一些项目被引用，而一些项目没有依赖性？
我检查了我的引用（至少在某些情况下我看到它不起作用）并且它们是项目引用而不是 dll。
我的一些同事使用完全相同的代码（获取最新版本的代码而无需更改）没有遇到此问题，并且在 Visual studio 中显示了依赖项。
所以我最后删除了解决方案文件附近的 *.sdf 文件（在关闭 visual studio 之后）。我重新打开和 tadaa，所有依赖项都已由 visual studio 重新计算。现在我rebuild，直接一切成功。
我不确定为什么会这样，我有一些时间来消磨时间 visual studio，也许那时有些东西被破坏了。
我知道这不是解决方案，但如果您使用依赖注入技术（如 MEF 或 Unity），您可以将编译依赖项转换为运行时依赖项。
在这种情况下，您的项目具有有限的依赖项（接口、容器）。
但我不得不说，这些技术有一些副作用 - 比如 'pseudo random' 初始化等等...