在 MSBuild 中生成版本号答案

【问题标题】：Generating version number in MSBuild在 MSBuild 中生成版本号
【发布时间】：2012-12-29 20:09:30
【问题描述】：

我们有一个带有 WiX 安装程序和 MSBuild 构建脚本的 C# 解决方案。我们正在从 SVN 迁移到 Git。

作为我们版本号的第四部分，我们想要随着每次构建而提升的东西。到目前为止，我们一直使用 SVN 修订号。 MSBuild 脚本定义了一个 ProductVersion 属性，其中包括 SVN 修订号作为构建版本的四个数字的最后一个。但是，我们不能再使用它了，因为我们不再使用 SVN。

我一直在尝试寻找 SVN 修订号的替代品，但我不知道该使用什么。

Jenkins 提供了一个我可以使用的内部版本号，但我不想将我们的版本控制系统绑定到 Jenkins。
Jenkins 也提供了时间戳，但它不符合微软的版本号限制：它是字母数字并且有点长，而版本中的第 4 个数字应该是 0 到 65535 之间的整数。
我们可以将 AssemblyVersion 设置为 1.0.* 并让 .NET 填充其余部分。这适用于我们的程序集，但我找不到将其注入 WiX 的方法。一旦构建完成，我们就可以从其中一个程序集中获取它，但是我们的 MSBuild 脚本使用<MSBuild> 任务来立即构建整个解决方案，因此我们陷入了需要运行<MSBuild> 的 Catch-22 中它可以编译一个程序集，我们可以使用它来获取生成的版本号，但是为了运行<MSBuild>，我们首先需要有一个编译的程序集，以便我们可以从中获取生成的版本号。
我可以在 MSBuild 文件中添加一个单独的目标来编译某些东西（任何东西）并从中获取版本号，然后对 <MSBuild> 任务进行实际调用。但这感觉不对。

再一次，我真的不在乎这个数字是多少，只要它随着每次构建而递增。基于时间戳的东西会很好。有什么想法吗？

【问题讨论】：

【解决方案1】：

MSbuild Community Tasks 包含一个名为Version 的任务，它提供了一些算法来生成版本号。它非常易于使用和自定义。

恕我直言，最好使用一个与整个 SDLC 相关联的数字，这样您就可以将部署的产品跟踪到构建结果，并将这些跟踪到 VCS，等等。我建议像 Christopher Painter 那样使用 jenkins 内部版本号。

【讨论】：

我看到 BuildType="Automatic" 和 RevisionType="Automatic" 与 AssemblyVersion 中的 * 做同样的事情。好的！这为我解决了。

【解决方案2】：

您可以使用!(bind.FileVersion.FileId) 从程序集中获取版本号，其中FileId 是您的一个 wxs 文件中定义的 File 元素的 ID。

然后让 .NET 生成程序集编号，WiX 将使用它作为 ProductVersion。

【讨论】：

这就是我所指的catch-22：我使用哪个程序集？我必须先构建它...
我的意思是我可以这样做，但我必须将构建分成 2 个单独的步骤，而现在它是构建整个解决方案的一个干净简单的调用。
这正是我的做法，我不必分两步运行 MSBuild。由于 Wix 安装程序将引用 .NET 程序集/可执行文件，因此它将等到构建完成后再使用读取版本。我一般使用应用程序的主入口点作为要绑定的文件。
没错。当然，构建必须等到程序集构建完成才能构建安装程序？否则它怎么把这些程序集打包到安装程序中？
嗯，是的，现在我读回来了，听起来确实有点傻，对此感到抱歉:)。但是，我们实际上在同一个解决方案中有多个项目，每个项目都有自己的 WiX 安装程序。而且由于我不想在迁移到 git 的过程中进行 Big Wix 重构，这意味着在 6 个单独的 WiX 脚本中执行此操作，而以前，版本只是传入...

【解决方案3】：

你为什么不把它和詹金斯联系起来？似乎您希望 Jenkins 管理传递到构建中的属性，包括版本号。这就是我使用 BuildForge、TFS 等实现的方式。

【讨论】：

我也希望能够从命令行手动构建，而不是陷入版本控制问题。
我通常会执行 0.0.0.1 之类的操作。这样，如果我手动运行 MSBuild，它默认为 0.0.0.1，但如果我真正的构建自动化（TFS、BuildForge、Jenkins 等）运行它，我可以传递 /p:ProductVersion=1.2.3.4 并让它覆盖它。