在TeamCity中使用我的大型解决方案进行复杂的版本控制

可能毫无意义的背景故事

为了摆脱NuGet地狱(以前的依赖地狱)，我的团队决定转向更大的解决方案，专注于我们公司的主要部门。在过去，我们会有一个核心DLL，其中包含特定系统的最常见代码，以及通过NuGet将该DLL拉入的多个解决方案。这导致了大量的包，甚至更多的解决方案，这最终意味着每个部门的代码集合高度断裂。

我们的新方法是转向使用一个通过Web API公开的大型综合核心库。我们还计划在Web API性能不合适的情况下，通过NuGet包提供核心DLL。

一个基本的解决方案将有3个项目:核心，API和包装。Wrapper项目提供了通过简单方法访问API的方法，而不是在我们的应用程序中重写所有将使用它的Web API调用。更复杂的解决方案将有额外的项目，如Windows服务和控制台应用程序作为计划任务运行。

这3个基本项目将共享相同的版本号，因为它们是紧密耦合的。当包括其他不应该在其构建中使用相同版本号的项目时，问题就出现了。

真正的问题

我有一个解决方案，有4个项目:A, B, C和D, A-C总是一起更新并共享相同的版本号。D是一个服务项目，它有自己的逻辑，可以独立于其他项目进行更改，因此应该有自己的版本编号。但是，为了避免混淆，D应该与A-C的正确版本的dll一起部署。(这意味着如果D是2.0.0,A-C是1.0.0，那么安装目录中A-C的dll应该在其详细信息中显示1.0.0。)

考虑到这一点，在TeamCity中是否有一种方法来构建和控制版本编号，以便需要唯一的项目可以，并且仍然引用正确的依赖关系?

指出:

• 我知道最简单的解决方案是简单地将特殊项目移到自己的解决方案中并引用核心DLL，但这是我们试图摆脱的一部分。
• 我们希望能够在我们完成的文件上有正确的构建号，以及Git中有来自成功构建的标签。
• 据我所知，TeamCity中的AssemblyInfo patchcher功能只能覆盖整个版本。如果它可以简单地覆盖构建号，那么我就可以在我的源代码中控制版本号。