版本化.NET构建

只是想知道.NET构建版本化的最佳方法是什么？

我用:

TFS 2013用于版本控制

TFS门禁办理登机手续

Wix 3.8将代码打包到MSI文件

我想设置版本:

程序集(AssemblyInfo.cs,或所有项目中引用的共享程序集)

MSI包(使用Wix代码)

文档(例如,在构建的最终输出中的readme.txt文件内)

等等

理想的版本号将允许跟踪已安装的软件回到确切的源代码.
就像是:

..

我希望在解决方案附近的版本控制中存储一些简单文本\ XML文件的前两部分版本,因为我相信它们应该共存.开发人员将手动更新此文件(例如,遵循语义版本控制方法).每个构建都将读取此版本文件,从调用CI工具获取3d版本的部分,并使用该版本更新所有必需的文件.

实现这个的最佳方法是什么？

我过去曾使用过几种方法:

1)执行此版本的NAnt\MsBuild包装器,然后调用MsBuild获取解决方案.它可以从CI工具(Jenkins\TeamCity\etc)调用.

问题 - 当我构建解决方案两次时,与TFS门控签入的集成很难看.

2)自定义TFS构建过程模板

问题 - 它不是那么简单,并导致一些合并工作TFS升级.此外,在门控签到中还不存在变更集编号,因此我们只能使用先前的变更集ID.

3)解决方案中的单独MsBuild项目,它仅执行此版本控制任务,并配置为首先在VS解决方案的项目构建顺序中运行.

问题 - 需要在所有其他项目(包括所有未来的项目)中引用这个元项目,这些项目感觉很难看

我知道不同的MsBuild和TFS扩展包可以简化更新.这个主题不是关于哪一个是最好的.问题是方法论而不是技术问题.

我还认为,如果微软在其标准TFS构建模板中包含版本控制功能,那将是理想的选择.其他CI工具已经具有此功能(AssemblyInfo修补程序).

更新11/09/2014

我决定明确表达符合敏捷\持续交付最佳实践的版本控制原则:

1)能够再现任何历史建筑

2)由于1)并且根据CD原则,所有内容(源代码,测试,应用程序配置,环境配置,构建\包\部署脚本等)都存储在版本控制下,因此具有分配给它的版本

3)版本号与其适用的源代码紧密存储在一起

4)人们可以根据他们的业务\营销逻辑更新版本

5)该版本只有一个主副本,用于自动构建\包装过程的所有部分

6)您可以轻松地说出目标系统上当前安装了哪个版本的软件

7)已安装软件的版本必须明确标识用于构建它的源代码

8)比较版本比较低,哪些更高,以控制允许哪些升级\降级方案及其实现细节是非常简单的

更新15/09/2014

请看下面我自己的答案.
我很幸运能找到满足我所有要求的解决方案!