想知道.NET构建版本控制的最佳方法是什么？
我使用：
- TFS 2013进行版本控制
- TFS门禁检查
- Wix 3.8将代码打包到MSI文件中
我想设置以下内容的版本号：
- 程序集（AssemblyInfo.cs，或在所有项目中引用的共享文件）
- MSI包（在Wix代码中）
- 文档（例如在构建的最终输出中的readme.txt文件内部）
- 等等
理想的版本号应该允许追溯安装的软件到确切的源代码。类似于：
<Major>.<Minor>.<TFS_changeset_number>
我希望将我想要存储的版本的前两个部分存储在简单的文本\ XML文件中，与解决方案一起放入版本控制中，因为我认为它们应该在一起。开发人员将手动更新此文件（例如遵循语义化版本控制方法）。每个构建都将读取此版本文件，从调用CI工具获取版本的第三部分，并使用该版本更新所有必要的文件。
最佳实现方式是什么？
我过去尝试了一些方法：
1）NAnt \ MsBuild包装器执行版本控制工作，然后调用MsBuild解决方案。它可以从CI工具（Jenkins \ TeamCity \等）调用。
问题 - 与TFS门控提交的集成不美观，因为我需要两次构建解决方案。
2）自定义TFS构建过程模板
问题 - 它不太简单，并会导致TFS升级时进行一些合并工作。此外，在门控提交中还不存在变更集编号，因此我们只能使用先前的变更集id。
3）解决方案中的单独的MsBuild项目，仅执行此版本控制任务，并配置为在VS解决方案的Project Build顺序中首先运行。
问题 - 必须在所有其他项目（包括所有未来的项目）中引用此元项目，感觉不美观
我知道各种MsBuild和TFS扩展包可以简化更新。这个主题不是关于哪一个扩展包最好。这个问题比较方法论而不是技术性的。我还认为，如果Microsoft在其标准TFS构建模板中包含一些版本控制功能，那将是理想的选择。其他CI工具已经具备了这个功能（AssemblyInfo patcher）。
11/09/2014更新
我决定明确表达符合敏捷\持续交付最佳实践的版本控制原则：
1）能够重现任何历史构建
2）根据CD原则，作为第1点的结果，每个东西（源代码、测试、应用程序配置、环境配置、构建\打包\部署脚本等）都存储在版本控制下，因此分配了一个版本号
3）版本号紧密地与其适用的源代码一起存储
4）人们能够根据他们的业务\营销逻辑更新版本
5）只有一个主要版本副本，用于自动化构建\打包过程的所有部分
6）您可以轻松地说出目标系统当前安装的软件的版本号
7）安装的软件版本必须明确地标识用于构建它的源代码
8）很容易比较版本号以确定哪个版本较低或较高-控制允许哪些升级\降级方案及其实现细节
15/09/2014更新
请参见我的答案以下。
我很幸运找到了符合所有要求的解决方案！
