我有一个 msbuild 项目，它从 Visual Studio 构建一个 SLN 文件，其中包含所有项目（大约 70 多个项目），并且许多项目相互依赖，这意味着它们需要按顺序构建 - 有时开发人员会忘记在解决方案文件中的 Visual Studio 中手动设置构建顺序，导致干净解决方案上的 msbuild 失败，因为某些东西构建无序/找不到 dll。
msbuild 有没有办法获取所有项目并解决依赖关系并按顺序构建项目，如果有我该怎么做？使用 MSBuild 任务？对于当前的尝试，它似乎只是按照它读取项目的顺序构建 - 如果我传入项目文件+路径的列表。
目前我能想到解决这个问题的唯一方法是一个外部应用程序，它扫描项目文件和引用，然后每次手动创建一个解决方案..但这对于这么简单的事情来说似乎有点矫枉过正。
有人解决过/见过这个吗？
你怎么称呼MSBuild？如果将 MSBuild 指向解决方案文件，它应该能够解决依赖关系。如果您将其指向单个项目文件，那么它将无法解析任何项目引用。
如果您不使用项目引用，您仍然可以通过使用“项目依赖项”对话框手动设置依赖项来控制解决方案中的依赖项顺序。
虽然项目依赖项很难维护并且不能在 .sln 文件之间共享，但项目引用很受尊重，并且确实一致地规定了顺序 - 请参阅 .sln 中的ResolveReferences任务Microsoft.Common.targets。
旁白：“我的一个朋友”可能“在重构期间”不小心中断了他们的构建Task，并且它DependsOnTargets与任务的联系Microsoft.Common.targets ResolveReferences最终ProjectReferences没有以听起来像这里的问题的方式得到尊重。如果您阅读了其中的一些帖子，您可能会认为这一切都是疯狂的摇摇欲坠——事实并非如此；不稳定的位是项目依赖项，而不是项目引用。
请参阅Dan Moseley 撰写的这篇出色的 MSDN 博客文章，该文章真正解释了该主题，包括一些有用的变通策略。（通过这个与构建 xUnit.net 轻微相关的问题）。
如果您的所有依赖项目都在解决方案中，并且您正在使用项目引用，则 Visual Studio 应管理您的依赖项并按照该依赖项列表的顺序构建。
听起来您没有使用项目引用。我总是推荐项目参考。
这是一个老问题，但问题很可能是解决方案中的项目使用了对依赖 DLL 的直接引用（添加引用 > 选择浏览选项卡 > 选择依赖 DLL）而不是使用项目引用（添加引用 > 选择项目选项卡 > 选择依赖项目）。使用直接引用，Visual Studio 无法找出依赖链。您必须通过右键单击解决方案节点并选择属性来告诉它。选择 Common Properties > Project Dependencies 来设置所需的项目。克劳斯先生是正确的，但我想记录如何解决这个问题。
没有任何 Microsoft 工具可以检查您的 70 多个项目的所有依赖项并生成一个解决方案文件，其中明确为您声明了依赖项。
您必须使用 2 种不同的方法自行完成：
如果您不想这样做，那么您将不得不吞下药物并接受您将使用外部工具为您执行此操作的事实。是的，它很笨重，但可以让它工作。如果您将解决方案文件签入源代码管理，则可以缓解这些问题。只要您有一个活动的解决方案文件可以使用。
我有一次没有，我在构建中有 600 多个项目。所以我写了一个工具（几年前），它可以自动化 99% 的工作。它使用 .NET MSBuild API 来读取 msbuild 文件（这里没有使用 xml api 重新创建轮子）。然后它检查输出和输入并生成一个依赖树，然后我可以用它做一些事情：
我使用该工具看到的唯一限制是一些疯狂的 COM 依赖项，这些依赖项无论如何都非常粗略。我添加了一个超级简单的解决方法。
虽然在使用项目依赖项时 MSBuild 应该遵守构建顺序是正确的，但有一个警告。目前，在构建干净目标时，它不会观察反向构建顺序（正如我在此处写的博客）。但是，对于常规构建，它可以很好地工作，正如此处其他人所描述的那样。
我正在使用位于 c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 的 Msbuild 4 似乎可以解决问题。