visual-studio MSBuild - 它可以解决解决方案文件中的项目依赖关系吗？如果是这样怎么办？

MSBuild - can it work out project dependencies in a solution file? If so how?

提问by Dave

I have an msbuild project which builds a SLN file from visual studio which holds all the projects in (about 70+ project), and a lot of the projects are dependent on each other meaning they need to be build in order - sometimes a developer forgets to set the build order manually in visual studio in the solution file causing the msbuild on a clean solution to fail as something gets built out of order/cant find a dll.

我有一个 msbuild 项目，它从 Visual Studio 构建一个 SLN 文件，该文件包含所有项目（大约 70 多个项目），并且许多项目相互依赖，这意味着它们需要按顺序构建 - 有时开发人员会忘记在解决方案文件中的 Visual Studio 中手动设置构建顺序，导致干净解决方案上的 msbuild 失败，因为某些内容构建无序/找不到 dll。

Is there a way for msbuild to take all projects and work out the dependencies and build the projects in order, if there is how do i do this? using an MSBuild task? With current tries it seems to just build in the order it reads the projects in - if i pass in a list of project files+paths.

有没有办法让 msbuild 获取所有项目并确定依赖项并按顺序构建项目，如果有的话我该怎么做？使用 MSBuild 任务？通过当前的尝试，它似乎只是按照它读取项目的顺序构建 - 如果我传入项目文件+路径的列表。

Currently the only way i can think to solve this is a external app which scans the proj files and references and then manually creates a solution each time.. but this seems overkill for such a simple thing.

目前，我认为解决此问题的唯一方法是使用外部应用程序扫描项目文件和引用，然后每次手动创建一个解决方案。

Anyone solved / seen this before?

有人解决过/见过这个吗？

回答by Scott Dorman

How are you calling MSBuild? If you point MSBuild to the solution file, it should be able to work out the dependencies. If you point it to individual project files, then it won't be able to resolve any project references.

你如何调用 MSBuild？如果您将 MSBuild 指向解决方案文件，它应该能够计算出依赖项。如果您将其指向单个项目文件，则它将无法解析任何项目引用。

If you don't use project references you can still control the dependency order in a solution by using the "Project Dependencies" dialog to manually set the dependencies.

如果您不使用项目引用，您仍然可以通过使用“项目依赖关系”对话框手动设置依赖关系来控制解决方案中的依赖关系顺序。

回答by Ruben Bartelink

While Project Dependencies are hard to maintain and not shared across .sln files, Project Referencesare honoured and do dictate the order consistently - see the ResolveReferencestask in Microsoft.Common.targets.

虽然项目依赖项难以维护并且不能在 .sln 文件之间共享，但项目引用受到尊重并且确实一致地规定了顺序 - 请参阅.sln 中的ResolveReferences任务Microsoft.Common.targets。

ASIDE: A 'friend of mine' may 'during a refactoring' have accidentally stubbed out their Build Taskand it's DependsOnTargetslinkage to the Microsoft.Common.targetsResolveReferencestask and ended up with ProjectReferencesnot being honoured in ways that sound like the question here. If you read some of the posts, you might get the idea that it's all mad shaky - it's not; the shaky bits are the Project dependencies, not the Project references.

旁白：“我的朋友”可能“在重构期间”不小心删除了他们的 BuildTask和它DependsOnTargets与Microsoft.Common.targetsResolveReferences任务的联系，最终ProjectReferences没有以听起来像这里的问题的方式得到尊重。如果您阅读了一些帖子，您可能会认为这一切都太疯狂了——事实并非如此；不稳定的部分是项目依赖项，而不是项目引用。

---

---

See this excellent MSDN Blog article by Dan Moseleythat really explains the topic, including some useful workaround strategies. (via this mildly related issue with building xUnit.net).

请参阅Dan Moseley 撰写的这篇出色的 MSDN 博客文章，该文章真正解释了该主题，包括一些有用的变通策略。（通过这个与构建 xUnit.net 的温和相关的问题）。

回答by Sixto Saez

This is an old question but the issue was most likely that projects in the solution used direct references to dependent DLLs (Add Reference > select Browse tab > select dependent DLL) instead of using project references (Add Reference > select Projects tab > select dependent project). With direct references, Visual Studio can't figure out the dependency chain. You must tell it by right clicking on the solution node and select Properties. Pick Common Properties > Project Dependencies to set the required projects. Mr. Klaus is correct but I wanted to document how to fix this issue.

这是一个老问题，但问题很可能是解决方案中的项目使用了对依赖 DLL 的直接引用（添加引用 > 选择浏览选项卡 > 选择依赖 DLL）而不是使用项目引用（添加引用 > 选择项目选项卡 > 选择依赖项目） ）。使用直接引用，Visual Studio 无法找出依赖链。您必须通过右键单击解决方案节点并选择属性来告诉它。选择 Common Properties > Project Dependencies 来设置所需的项目。克劳斯先生是对的，但我想记录如何解决这个问题。

回答by Mr. Kraus

If all of your dependent projects are in the solution and you are using Project references, Visual Studio should manage the dependencies for your and build in order of that dependency list.

如果您的所有依赖项目都在解决方案中并且您正在使用项目引用，则 Visual Studio 应管理您的依赖项并按照该依赖项列表的顺序进行构建。

It sounds like you are not using project references. I always recommend project references.

听起来您没有使用项目引用。我总是推荐项目参考。

回答by Mr. Kraus

While it is correct that MSBuild should observe the build order when you use project dependencies there is one caveat. It doesn't at present observe the reverse build order when building the clean target (as I have blogged about here). For regular build however it works nicely as described by others here.

虽然在使用项目依赖项时 MSBuild 应该遵守构建顺序是正确的，但有一个警告。建设清洁目标时（如我的博客上讲述它目前不遵守逆向构建顺序在这里）。然而，对于常规构建，它可以很好地工作，正如其他人在此处描述的那样。

回答by Henry Aloni

I am using Msbuild 4 found at c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe It seems to solve the problem.

我正在使用位于 c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 的 Msbuild 4 似乎解决了问题。

回答by C Johnson

There is no Microsoft tool that will examine all the dependencies of your 70+ projects and generate a solution file with dependencies clearly declared for you.

没有 Microsoft 工具可以检查您 70 多个项目的所有依赖项并生成一个解决方案文件，其中为您明确声明了依赖项。

You have to do that on your own by using 2 different methods:

您必须使用 2 种不同的方法自行完成此操作：

1. Manually specify a dependency, for the solution, in visual studio.
2. Specify a project reference in the project file itself.

1. 在 Visual Studio 中为解决方案手动指定依赖项。
2. 在项目文件本身中指定项目引用。

If you don't want to do that, then you will have to swallow the medicine and accept that you will to use an external tool to do that for you. Yes it's clunky but it can be made to work. If you check in your solution file to your source control you can mitigate these problems. As long as you have an active solution file to work with.

如果您不想这样做，那么您将不得不吞下药物并接受您将使用外部工具为您做这件事。是的，它很笨重，但它可以工作。如果将解决方案文件签入源代码管理，则可以缓解这些问题。只要您有可用的活动解决方案文件。

I at one point didn't, and I had 600+ projects in the build. So I wrote a tool (years ago) that would automate 99% of this work. It uses the .NET MSBuild API's to read the msbuild files (no recreating the wheel here with xml api's). It then examines outputs and inputs and generate a dependency tree which I can then do a few things with it:

我曾经没有，而且我在构建中有 600 多个项目。所以我写了一个工具（几年前）可以自动化 99% 的这项工作。它使用 .NET MSBuild API 来读取 msbuild 文件（这里没有使用 xml api 重新创建轮子）。然后它检查输出和输入并生成一个依赖树，然后我可以用它做一些事情：

1. Spit out a solution file.
2. Do a dependency sort (also a topological sort in academia), and spit out those projects in order they should be built (for a non-parallel type of build, which can be useful sometimes).
3. print out all sorts of diagnostic information about dependencies.

1. 吐出一个解决方案文件。
2. 做一个依赖排序（在学术界也是一种拓扑排序），然后按照应该构建的顺序吐出这些项目（对于非并行类型的构建，这有时很有用）。
3. 打印出有关依赖项的各种诊断信息。

The only limitation I have seen with the tool is with a few crazy COM dependencies which are pretty sketchy anyways. Which I added a super simple work-around.

我在该工具中看到的唯一限制是一些疯狂的 COM 依赖项，无论如何这些依赖项都非常粗略。我添加了一个超级简单的解决方法。