使用 TeamCity 进行程序集版本控制

Question

我正在开发一个使用 SVN 和 TeamCity 构建服务器的 C#/VB.Net 项目。 构建过程中会产生十多个组件。 我想控制程序集版本，以便它们全部匹配并匹配 TeamCity 构建标签。

我已将 TeamCity 配置为使用以下构建标签

主要.次要.{构建}.{修订}

其中 Major 和 Minor 是我手动设置的常量，{Revision} 由签出时的 SVN 存储库版本确定，而 {Build} 是 TeamCity 自动递增构建计数器。 所以一个示例构建标签是

2.5.437.4423

您建议采用哪些技术来确保所有程序集版本都与 TeamCity 构建标签匹配？

Answer 1

尽管这已经有了一个公认的答案，但我想添加一个我们已经使用过的想法。

对于大型项目，可能有许多程序集信息文件需要更新，并且通过不断的重构，始终存在构建脚本不知道需要更新的新文件的风险。

因此，我们创建了一个简单的代码文件，它为实际版本定义了一个常量，然后所有项目都继承该常量并在程序集信息文件中继承我们。 那么构建脚本只需要更新一个文件。

这里的另一个好处是，这也稍微加快了构建过程，因为它不需要遍历许多文件并进行更改。

Answer 2

我建议使用 TeamCity 的 AssemblyInfo 修补程序构建功能：

http://confluence.jetbrains.net/ display/TCD65/AssemblyInfo+Patcher

只需从 VisualStudio 创建项目，在 BuildSteps 页面中配置构建功能（请参阅 http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features），只要保留默认的 AssemblyInfo.cs 文件，它就可以工作。

这种方法对我来说非常有效。

优点：

• 开发人员可以在他们的机器上构建解决方案。
• 您不需要接触 .sln 或 .csproj 文件。 它就是有效的。
• 通过使用 TeamCity 变量，您可以轻松地使版本号与其他项目的版本相匹配等。

缺点：

• 您无法轻松地从 TeamCity 切换到另一个 CI 服务器，因为您没有构建脚本（但是切换 CI 服务器就像切换ORM 或数据库：这不太可能，并且无论如何都需要大量工作）。

Answer 3

我将哈米什的答案保留为已接受的答案，但为了完整起见，我认为值得记录我们最终采用的方法。

我在 TeamCity 中维护 2 个单独的构建配置，一个是 CI 构建，另一个是在有任何更改（或手动）时每周运行的构建，并且是我们的官方发布构建。 我选择了两次构建方法，因为构建端到端大约需要 40 分钟，并且我希望开发人员在提交更改时能够获得有关任何构建问题的快速反馈。 因此，CI 构建是完整发布构建的子集，但它确实构建了所有代码。 两个版本之间的版本控制也有所不同：

• CI 版本的版本号为 {Major.minor.BuildCounter.SvnRevision}
  • BuildCounter从0开始
  • 不标记 svn 存储库
• Weekly/Release 构建具有类似的版本控制系统，但是
  • 构建计数器从 (Major * 1000) 开始，因此如果 Major 为“8”，则构建计数器从 8000 开始。
  • 在 svn 存储库中创建一个名为“Build_{Version}”的标签

这样做的原因有些随意选择是为了让我们能够清楚、简单地区分 CI 构建和 Release 构建。

我们有一个名为 AssemblyVersionInfo 的解决方案范围文件，该文件包含（软链接）在解决方案的每个项目中。 该文件（实质上）包含以下内容：

using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer's private workstation.
[assembly: AssemblyFileVersion("6.0.9999.9999")]        // Win32 File Version (not used by .NET)

因此，开发人员构建的所有版本都使用相同的静态且易于识别的版本号，该版本号高于构建服务器生成的任何版本号，因此在版本控制冲突中，开发人员的文件获胜。

在构建服务器上，我们使用 MSBuild 社区任务生成一个新的 AssemblyVersionInfo 文件来覆盖默认内容。 我们使用 TeamCity 构建字符串作为新版本。 这样，我们就可以轻松区分以下 3 种情况：

• 在开发人员工作站上执行的私有构建
• 在构建服务器上执行的 CI 构建，但不应发布该构建
• Svn 存储库中进行标记

官方批准的发布构建，在 另一个变化，请注意我设置的是 AssemblyFileVersion，而不是 AssemblyVersion。 我们强制我们的程序集版本为静态、固定版本字符串“Major.Minor.0.0”。 我们这样做是为了能够发布错误修复版本，而不必担心版本控制问题。 AssemblyFileVersion 可以让我们了解用户安装的版本，而无需将其作为程序集标识的一部分。

Answer 4

我们使用 CruiseControl.net 和 SVN。 我们以另一种方式驾驶它。 我们在 MSBuild 脚本中使用 MSBuildCommunityTasks 版本任务来增加 CI 构建的版本号并使用该版本用于标记源代码的编号。

编辑：询问有关 MSBuild 目标的更多详细信息...
我们使用一个单独的脚本用于 CI 构建，而不用于开发人员构建。 我们尝试在 Studio 用作项目文件的 MSBuild 文件中使用不同的目标，但这很令人头痛，并且需要手动编辑 Studio 生成的文件。
MSBuild 文件的结构非常简单：

1. 导入额外的部分

   <导入项目=“$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets”/>
   
   

2. BeforeBuild：设置新版本号并重写AssemblyInfo文件

   
   

   
   

   
   

   
   

   
   

   
   
OutputFile="Properties\AssemblyInfo.cs"
AssemblyTitle="$(TargetAssembly)"
AssemblyDescription="$(AssemblyDescription) svn:@(SanitizedSvnUrl) 修订版:$(SvnRevision)"
AssemblyCompany="您的公司名称"
AssemblyProduct="产品名称"
AssemblyCopyright="版权所有 © 贵公司 2009"
ComVisible="false" Guid="$(WindowGuid)"
AssemblyVersion="$(主要).$(次要).$(构建).$(修订)"
AssemblyFileVersion="$(主要).$(次要).$(构建).$(修订)"
Condition="$(Revision) != '0' " />

3. Build：在发布模式下构建实际的项目文件 MSBuild 脚本

4. AfterBuild：我们运行我们的单元测试项目（作为防止在后续步骤中为损坏的构建创建标签的防护），使用 SvnInfo 任务和一些 RegexReplace 任务来设置一些带有路径和标签名称的变量，并使用 SvnCopy 任务创建标签。


密码=“密码”
SourcePath="@(SvnTrunkPath)"
DestinationPath="@(SvnTagsPath)/BUILD-$(TargetAssembly)-$(主要).$(次要).$(构建).$(修订)"
Message="标记成功构建"/>