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

可能毫无意义的背景故事

为了摆脱NuGet hell（以前称为dependency hell），我的团队决定转向更大的解决方案，专注于公司的主要部门。在过去，我们会有一个核心DLL，其中包含特定系统的最常见代码，并有多个解决方案通过NuGet将该DLL引入。这导致了大量的包，甚至更多的解决方案，这最终意味着每个部门都有一个高度分散的代码集合

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

基本解决方案将有3个项目：核心、API和包装器。包装器项目提供了通过简单方法访问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修补程序功能只能覆盖整个版本。如果它可以简单地覆盖版本号，那么我就可以在源代码中控制版本号

---

您是对的，AssemblyInfo补丁程序在这种情况下没有帮助，因为它会更新所有AssemblyInfo文件或全局AssemblyInfo文件。恐怕没有直截了当的方法，但我认为您可以尝试以下方法：

• 不要构建解决方案，而是使用.csproj文件构建单个项目，即将编译分为4个步骤，每个项目一个步骤（A-D）
• 将AssemblyInfo修补程序用于A-C项目，这样他们就可以简单地使用Teamcity版本

  %build.number%

• 向D csproj添加预生成事件以更新其assemblyinfo信息。您需要在teamcity中为其版本的前3位（如DVersion（1.0.0））定义一个变量，它的最后一部分可以来自

  %build.counter%

  变量。将此版本（%DVersion%。%build.counter%）作为参数传递给D csproj文件生成步骤
• 最后，通过将日志写入类似于

  ##teamcity[buildNumber'%build.number%-%DVersion%']的内容来更新teamcity内部版本号。

---

我很想知道为什么应该关闭……它被标记为“太宽”，这似乎是正确的。SO的目的是解决开发（代码）问题，而不是开发环境问题。尤其不要推荐开发和存储库命名解决方案。我感觉到你的痛苦（也理解你的问题），但这对SO来说是一个非常大的问题。这个网站上有很多与TeamCity和版本控制相关的问题。我不是在要求任何形式的命名解决方案。我可能在答案上有点胡作非为——我是罪魁祸首。注：我没有投票决定结束。