使用程序集版本控制属性的最佳方法是什么?

我在这里看到许多关于使用subversion修订号作为汇编版本的组件的帖子。 注意:windows中可用的4个版本号(a.b.c.d)均限制为16位(最大值为65535)。 subversion版本号很容易超过此限制,尤其是在同一存储库中托管多个项目时。

我们一开始只是简单地增加版本号,但这需要为每个版本签入版本文件,并且在合并时会导致冲突。当这被证明不可行时,我们开始使用CruiseControl.NET来生成构建编号,但这使得手动复制特定构建变得困难。最终我们采用了当前的(颠覆修订)方案。

注意:遗憾的是,对于.NET,不可能完全从以前的版本重新创建生成,因为.NET编译器在编译时将当前时间戳编码到对象文件中。每次编译相同的代码时,都会得到不同的对象文件。

在以前的工作中,我们使用了Subversion,我让一个nant脚本在ccnet上运行,以提取存储库版本,并将其作为最终的数字。

在这项工作中,我们使用VSS(shutter),因此这不是一个真正的选项,因此我们有一个手动更新它的策略,遵循以下准则:

• 次要:功能或界面上的微小变化或增加。
• 修订版:修复不更改接口的生成。

我们还保留了组装和;文件版本同步。程序集版本可以通过编程方式轻松读取,而文件版本可以在Windows资源管理器中以详细信息模式显示为列。

我们的构建脚本将TFS中的变更集编号注入到版本中。这样我们就可以确切地知道构建中的签入是什么。

AssemblyFileVersion 这使我们能够追溯到构建服务器构建的任何程序集的源代码。(我们总是从主分支开始构建。)

对于客户将引用的程序集,我们保留 AssemblyVersion

我们使用subversion的版本控制,并让构建脚本更新程序集版本信息,因此源签入控制版本控制。

我们倾向于将发布(或构建)日期嵌入到程序集中。例如,如果今天构建,则版本将为“2008.10.06”(构建脚本将对其进行更新)。