基于TeamCity的装配版本控制

Question

我正在开发一个使用SVN和TeamCity构建服务器的C#/VB.Net项目。由生成生成的程序集大约有十几个。我希望控制程序集版本，以便它们都匹配，并匹配TeamCity构建标签。

我已经将TeamCity配置为使用

Major.Minor.{Build}.{Revision}

如果主要和次要是我手动设置的常量，则{ set }由签出时的SVN存储库版本确定，{ build }是一个TeamCity自动递增生成计数器。因此，构建标签的示例应该是

2.5.437.4423

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

Answer 1

我们使用的是CruiseControl.net和SVN。我们把它开向另一边。我们使用MSBuildCommunityTasks脚本中的MSBuild版本任务来增加CI构建的版本号，并使用该版本号标记源代码。

编辑：要求更多关于MSBuild目标的详细信息.

我们使用单独的脚本，用于CI构建，而不是用于开发人员构建。我们尝试在工作室作为项目文件使用的MSBuild文件中使用不同的目标，但这让人头疼，需要手动编辑工作室正在生成的文件。

MSBuild文件的结构非常简单：

1. 进口额外的零件 <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" /> <!-- contains some variables that set project names, paths etc. --> <Import Project="Properties.msbuild"/>
2. BeforeBuild:设置新版本号并重写AssemblyInfo文件<Version VersionFile="$(VersionFile)" BuildType="None" RevisionType="Increment"> <Output TaskParameter="Major" PropertyName="Major" /> <Output TaskParameter="Minor" PropertyName="Minor" /> <Output TaskParameter="Build" PropertyName="Build" /> <Output TaskParameter="Revision" PropertyName="Revision" /> </Version> <!--Modify Assembly Info--> <AssemblyInfo CodeLanguage="CS" OutputFile="Properties\AssemblyInfo.cs" AssemblyTitle="$(TargetAssembly)" AssemblyDescription="$(AssemblyDescription) svn:@(SanitizedSvnUrl) revision:$(SvnRevision)" AssemblyCompany="Your company name" AssemblyProduct="Name of product" AssemblyCopyright="Copyright © your company 2009" ComVisible="false" Guid="$(WindowGuid)" AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" Condition="$(Revision) != '0' " />
3. 构建:在发布模式下构建实际的项目文件MSBuild脚本
4. AfterBuild:我们运行单元测试项目(为了防止在接下来的步骤中为损坏的构建创建标记)，使用SvnInfo任务和一些RegexReplace任务设置一些带有路径和标记名的变量，并使用SvnCopy任务创建标记。

<SvnCopy UserName="username"

Password="password"

SourcePath="@(SvnTrunkPath)"

DestinationPath="@(SvnTagsPath)/BUILD-$(TargetAssembly)-$(Major).$(Minor).$(Build).$(Revision)" Message="Tagging successful build" />

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

我把Hamish的答案作为可接受的答案，但为了完整起见，我认为值得记录我们最终采用的方法。

我在TeamCity中维护了两个独立的构建配置，一个是CI构建，另一个是当有任何更改(或手动)时每周运行的构建，这是我们的正式版本构建。我采用了两种构建方法，因为构建需要40分钟的端到端时间，我希望开发人员在提交更改时能够得到关于任何构建问题的快速反馈。因此，CI构建是整个发行版构建的一个子集，但它确实构建了所有代码。版本控制在这两个版本之间也不同：

• CI构建具有版本号{Major.minor.BuildCounter.SvnRevision}
  • BuildCounter从0开始
  • 不标记svn存储库。

​

• Weekly/Release有类似的版本控制系统，但是
  • 生成计数器从(主* 1000)开始，因此如果主计数器为'8'，则生成计数器从8000开始。
  • 在svn存储库中创建一个名为“Build_{Version}”的标记

​

这种有点任意性的选择的原因是为了让我们能够清楚和简单地区分CI构建和发布构建。

我们有一个名为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)

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

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

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

另外，请注意，我设置的是AssemblyFileVersion，而不是AssemblyVersion。我们强制我们的程序集版本是一个静态的固定版本字符串'Major.Minor.0.0‘。我们这样做是为了能够发布bug修复版本，而不必担心版本控制问题。AssemblyFileVersion可以让我们知道用户安装了什么构建，而不需要将其作为程序集标识的一部分。