我们有一个带有WiX安装程序和MSBuild构建脚本的C＃解决方案。我们正在从SVN迁移到Git。
作为我们版本号的第四部分，我们希望每次构建都能提升。到目前为止，我们已经使用了SVN版本号。 MSBuild脚本定义了一个ProductVersion属性，其中包含SVN修订版号作为构建版本的四个数字的最后一个。但是，我们不能再使用它，因为我们将不再使用SVN。
我一直试图找到SVN版本号的替代品，但我无法弄清楚要使用什么。
Jenkins提供了我可以使用的内部版本号，但我不想将我们的版本控制系统绑定到Jenkins。
Jenkins还提供时间戳，但它不符合Microsoft的版本号限制：它是字母数字且有点长，而版本中的第4个数字应该是0到65535之间的整数。
我们可以将AssemblyVersion设置为1.0。*并让.NET填写其余部分。这适用于我们的程序集，但我找不到将其注入WiX的方法。我们可以在构建之后从其中一个程序集中获取它，但我们的MSBuild脚本使用<MSBuild>任务一次构建整个解决方案，因此我们陷入了需要运行的Catch-22 {{ 1}}所以它可以编译我们可以用来获取生成的版本号的程序集，但是为了运行<MSBuild>，我们首先需要一个已编译的程序集，以便我们可以从中获取生成的版本号
我可以在MSBuild文件中添加一个单独的Target来编译某些东西（任何东西）并从中获取版本号，然后对<MSBuild>任务进行实际调用。但那只是感觉不对。
同样，我并不关心数字是什么，只要它随着每次构建而增加。基于时间戳的东西会很好。有什么想法吗？
答案 0 :(得分：7)
MSbuild Community Tasks包含一个名为Version的任务，它提供了一些生成版本号的算法。它非常易于使用和定制。
恕我直言，最好使用一个与整个SDLC相关联的数字，这样您就可以将已部署的产品跟踪到构建结果，将这些产品跟踪到VCS，依此类推。我建议使用jenkins内部编号，正如Christopher Painter所做的那样。
答案 1 :(得分：1)
您可以使用!(bind.FileVersion.FileId)从程序集中获取版本号，其中FileId是您在某个wxs文件中定义的File元素的ID。
然后让.NET生成程序集编号，WiX将其用作ProductVersion。
答案 2 :(得分：0)
为什么你不把它绑在詹金斯身上？好像您希望Jenkins管理传递到包含版本号的构建的属性。这就是我使用BuildForge，TFS等人
的方式