我们有一个应用程序，它的组件是在多个 Visual Studio 解决方案 (.sln) 中开发的。有时会添加或删除解决方案。将 DLL 等构建输出复制到共享文件夹中。来自其他解决方案的项目引用这些 DLL。这是一个简化的示例：解决方案 A 和 B 各包含两个项目。方案B的项目B2引用了方案A的项目A2。
旁注：我们正在使用 NuGet 包替换共享驱动器；但是，下面的问题仍然很明显。
TeamCity 支持构建依赖项。这个video 演示了如何手动设置它。
但是，我们希望 TeamCity 自动（！！）解决项目之间的依赖关系。因此，在上面的示例中，我们希望 TeamCity 首先构建解决方案 A，然后构建解决方案 B。我们如何配置 TeamCity 以自动获取这些依赖项而无需手动维护它们？
【问题讨论】：
标签： .net build continuous-integration teamcity projects-and-solutions
很遗憾，它不能自动执行。您可以考虑编写自己的插件。
您通常会设置快照依赖项，在您的示例中，B 构建将对 A 构建具有快照依赖项。
如果您移至 NuGet，它将恢复解决方案所引用的任何内容。您可能想要像上面那样拥有快照依赖，但不是必需的，每个解决方案都会确定它需要什么。
我认为您应该可以使用Rest API 来完成此操作，文档不是很清楚，但我确实找到了此gist，其中包含添加和删除快照的示例。
您可能需要制定一些设置项目的约定，以便更轻松地匹配项目。
您还应该查看 plugins page 以获取抽象 API 的库。
【讨论】：
我在JetBrains Developer Community 中问过这个问题。 JetBrain 对此的评论：
[...] 这不是 TeamCity 特有的问题，因为我希望您 应该能够在本地重现这样的构建过程 开发机器。 [...] .net 生态系统本身并不提供 解决方案。 [...] 可以选择编写自己的插件 msbuild 或生成解决方案（.sln 文件）。 [...]
换句话说：即使使用最新版本TeamCity 9，也没有开箱即用的自动化方法来解决所描述的问题。从完全手动设置到自定义工具，有多种选择：
【讨论】：
与将程序集放在共享驱动器上相比，NuGet 无疑是一种更好的方法，因此我很高兴看到您正朝着这个方向前进。
至于在构建依赖项目后自动构建消费项目，您有几个选项可以触发构建。要么：
下一部分很棘手，您有几个（艰难的）选择。 您面临的挑战是包是在 packages.config 中定义的，虽然您可以使用 NuGet 更新来更新包，但您需要决定是否希望 TeamCity 签入更改。所以关于你可以做什么的一些想法是：
我建议您从 1) 开始，然后在您对工作流程有信心并且事情没有出错时继续进行 2)。
您正在尝试做的事情非常艰难，所以我希望我已经为您提供了更多解决方案以供您考虑。但我认为这是一项有价值的练习，从长远来看会对你有所帮助。不幸的是，没有一刀切的，所以你必须试验和成熟你的过程。
虽然 TeamCity 是一个很棒的系统，但在您尝试使用它的方式方面确实存在不足。我建议看看 ThoughWorks GO。它更适合您想要实现的目标，但遗憾的是不如 TeamCity 直观和成熟。 http://www.go.cd
【讨论】：