维护程序集版本号的最佳实践/指导

Question

我正在寻找关于如何管理.NET程序集的三个不同程序集版本号的指针,建议甚至口述.产品版本是最简单的,因为这似乎通常由业务决定.然后,文件版本似乎用于部署之间的版本控制,其中实际的程序集版本仅在发货时使用.

现在我只是想找一个简单的方法来标记组件的测试和维护版本,而这些版本都没有依赖,因此我正在考虑在文件版本上自动递增构建和修订版本号,并且为了最终版本,复制当前版本文件版本到程序集版本.该产品正在生产中使用,但仍在开发中 - 您知道 - 其中一家小公司,没有变更控制基础设施的情况.

Answer 1

版本控制是我非常热衷的事情,并且花了很长时间试图想出一个易于使用的版本控制系统.根据您在问题中已经说过的内容,很明显您已经理解了一个重要的观点,即汇编版本号与产品版本不同.一个是技术驱动,另一个是业务驱动.

以下假定您使用某种形式的源代码控制和构建服务器.对于上下文,我们使用TeamCity和Subversion/Git.TeamCity对于少数(10)个项目是免费的,并且是一个非常好的构建服务器,但还有其他一些,其中一些是完全免费的.

版本号的含义

一个版本对一个人意味着什么可能意味着另一个人不同,一般结构是主要的,次要的,宏观的,微观的.我查看版本号的方法是将其分为两部分.上半部分描述了主要版本(Major)和任何关键更新(Minor).下半部分表示它何时构建以及源代码版本是什么.根据上下文,版本号也意味着不同的东西,它是API,Web App等.

Major.Minor.Build.Revision

• Revision 这是从源代码控制中获取的数字,用于标识实际构建的内容.
• Build这是一个不断增加的数字,可用于在构建服务器上查找特定的构建.这是一个重要的数字,因为构建服务器可能使用不同的参数集两次构建相同的源.将构建号与源号一起使用可以识别构建的内容和方式.
• Minor这应该只在公共接口发生重大变化时才会改变.例如,如果它是一个API,消费代码仍然可以编译？当主要号码改变时,该号码应重置为零.
• Major表示您所使用的产品版本.例如,所有VisualStudio 2008程序集的主要部分为9,VisualStudio 2010为10.

规则的例外

规则总是存在例外情况,您必须在遇到它们时进行调整.我最初的方法是基于使用颠覆,但最近我已经转移到Git.使用中央存储库的源控件(如subversion和source safe)具有一个可用于标识给定时间内特定源集的数字.对于诸如Git的分布式源控件,情况并非如此.因为Git使用每个开发机器上的分布式存储库,所以没有可以使用的自动递增数字,有一个hack使用了签到的数量,但它很难看.因此,我必须改进我的方法.

Major.Minor.Macro.Build

修订号现在已经消失,构建已经转移到以前修改的位置和宏已插入.你可以使用你看起来合适的宏,但大部分时间我都不管它.因为我们使用TeamCity,从版本号中丢失的信息可以在构建中找到,它确实意味着有两个步骤但我们没有丢失任何东西,并且是可接受的妥协.

要设置什么

首先要理解的是,程序集版本,文件版本和产品版本不必匹配.我并不主张使用不同的数字集,但是当对程序集进行小的更改而不会影响任何公共接口时,它会使生活变得容易得多,而不会强制您重新编译依赖程序集.我处理这个问题的方法是只在程序集版本中设置主要和次要数字,而是设置文件版本中的所有值.例如:

• 1.2.0.0(AssemblyVersion)
• 1.2.3.4(FileVersion)

这使您能够推出不会破坏现有代码的热修复,因为程序集版本不匹配,但允许您通过查看其文件版本号来查看程序集的修订版本/版本.这是一种常见的方法,当您查看程序集详细信息时,可以在某些开源程序集中看到它.

作为团队负责人,您需要负责在需要进行重大更改时递增次要编号.向接口推出所需更改但不破坏先前代码的一种解决方案是将当前代码标记为过时并创建新接口.这意味着现有代码被警告该方法已过时,可以随时删除,但不要求您立即中断所有内容.然后,您可以在迁移所有内容时删除过时的方法.

如何将它们连接在一起

您可以手动完成上述所有操作,但这将非常耗时,以下是我们如何自动化该过程.每个步骤都是可运行的.

• 从所有项目AssemblyInfo.cs文件中删除AssemblyVersion和AssemblyFileVersion属性.
• 创建一个公共程序集信息文件(称之为VersionInfo.cs)并将其作为链接项添加到所有项目中.
• 添加AssemblyVersion并AssemblyFileVersion赋值为值为"0.0.0.0"的版本.
• 创建一个构建解决方案文件的MsBuild项目.
• 在构建之前添加一个更新VersionInfo.cs的任务.有许多开源的MsBuild库包含可以设置版本号的AssemblyInfo任务.只需将其设置为任意数字并进行测试即可.
• 为构建号的每个段添加包含属性的属性组.这是您设置主要和次要的地方.构建和修订号应作为参数传递.

用subversion:

<PropertyGroup>
    <Version-Major>0</Version-Major>
    <Version-Minor>0</Version-Minor>
    <Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
    <Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
    <Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
    <Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>

希望我很清楚,但涉及很多.请问任何问题.我将使用任何反馈将更简洁的博客文章放在一起.

• 已编译程序集中的版本号
• MSBuild扩展包
• TeamCity的

Answer 2

[AssemblyVersion]在.NET中是一个非常大的问题.Microsoft鼓励的一个理念是让它自动增加,强制重新编译依赖于程序集的所有项目.如果您使用构建服务器,则可以正常工作.这绝不是错误的事情,但要小心携带剑的人.

另一种,其实际意义更密切相关的是,该数字是组件的公共接口的版本代表.换句话说,只有在更改公共接口或类时才更改它.由于只有这样的更改才需要重新编译程序集的客户端.这需要手动完成,但构建系统不够智能,无法自动检测此类更改.

您可以通过仅在将程序集部署到远程计算机之外的计算机上时增加版本来进一步扩展此方法.这是Microsoft使用的方法,它们的.NET程序集版本号很少更改.主要是因为它给客户带来了相当大的痛苦.

所以微软所宣扬的不是它的实践.然而,它的构建过程和版本控制是无与伦比的,甚至还有一个专门的软件工程师来监控这个过程.没有那么好用,WaitHandle.WaitOne(int)重载特别引起了相当大的痛苦.在.NET 4.0中使用一种非常不同的方法修复,但这有点超出了范围.

这取决于您和您对控制构建过程和发布周期的能力的信心,以便您自己做出选择.除此之外,自动递增[AssemblyFileVersion]是非常合适的.然而,不方便的是,这是不支持的.

Answer 3

您可以使用版本号的Build部分进行自动增量.

[assembly: AssemblyVersion("1.0.*")]

在您的环境中,测试版本是具有构建版本的版本!= 0.在发布时,您将增加次要部分并将构建部分设置为0,这是您识别已发布程序集的方式.

如果您在GAC中安装程序集,您的GAC会随着时间的推移而充斥着许多不同的版本,因此请记住这一点.但是如果你只在本地使用dll,我认为这是一个很好的做法.

Answer 4

添加到Bronumskis的答案,我想指出,在semver.org的Semantic Versioning 2.0标准之后,Major.Minor.Build.Revision由于规则增加一个数字后,右边的所有常规值都必须重置为零,这将是非法的.

遵循标准的更好方法是使用Major.Minor+Build.Revision.这显然不适合使用AssemblyVersionAttribute,但可以使用自定义属性或静态类.

TeamCity中的Semver应该可以使用Meta-runner Power Pack.对于使用git-flow的git(特别是在.NET世界中),我发现GitVersion很有帮助.