我有一些嵌入式C软件存储在TFS下，并且还有一个相应的TFS构建定义，可以成功检出代码并使用相关的编译器构建它。所以要明确一点，虽然这是TFS，但我还没有构建.NET应用程序。
现在我的构建工作正在进行中，我试图提供整体软件版本控制支持，该支持应该与构建过程相关联。我目前的目标如下：
正在构建的源代码有一个头文件，其中包含三个变量的#defines，Major Version，Minor Version和Build Number。然后，此头文件用于在编译时将版本号烘焙到软件中。概念是开发人员负责仅更新主要版本号和次要版本号作为开发的一部分。构建号始终保持为0，并且不应由开发人员修改。
在开发人员在自己的机器上本地生成构建的实例中，主要版本和次要版本将按照代码中的定义进行设置，但构建编号将保持为0，这表示不受控制的构建。但是，对于服务器上的官方构建，我希望TFS自动增加构建号，以便后续构建指定相同的主要版本和次要版本，从而导致构建号的增加以提供整体唯一版本描述符。
在做了一些阅读之后，我特别看到这个工作是将TFS内部版本号格式定义为如下所示： $ MajorVersion。$ MinorVersion。$（Rev：.rr）其中MajorVersion和MinorVersion是我定义为构建过程一部分的变量。
我意识到修订版基于整个版本号格式保持唯一性。所以我认为从源代码中提取主要版本和次要版本并在尝试评估修订版本和更广泛的版本号之前填充两个构建变量至关重要。我创建了一个Powershell脚本，使用正则表达式从头文件中提取主要版本和次要版本，然后在脚本中设置变量。
现在终于解决了这个问题。看来我的方法存在缺陷。一旦我对构建进行排队，就立即评估TFS构建号，似乎为排队的构建命名。在这个阶段，我无法运行我的脚本来提取主要版本和次要版本，因此也得到了错误的版本号。因此，基于我之前提到的内部编号格式，我最终得到的内容编号和结果名称类似于＆＃34; .. 01＆＃34;或＆＃34; 0.0.01＆＃34;取决于我是否初始化构建定义中的主要和次要变量。
所有人都可以看到我可以推迟评估TFS内部版本号的方法，直到我有机会通过Powershell构建步骤从源代码中读取我的主要和次要版本？如果我能这样做，则应根据真实的主要版本和次要版本正确计算修订版本。然后，我将使用另一个脚本在我的头文件中仅设置Build号#define以匹配TFS内部版本号中的修订版。此外，由于TFS似乎使用内部版本号作为排队构建的名称，因此我不知道如何处理此问题，因为我不知道构建点的最终TFS内部版本号排队。可以在构建过程中修改名称吗？
请帮忙。我认为我的想法相当简单，但我很难通过其他非常好的TFS 2015构建系统来实现它。
答案 0 :(得分：7)
TL; DR;您可以使用上面的内部版本编号格式，也可以创建自定义内部版本号...而不是两者。
使用Team Build，您可以在构建期间随时更新构建号，输出＆＃34; ## vso [build.updatebuildnumber] 1.2.3.4＆＃34;在构建期间到日志。
您可以在此处查看完整的日志记录命令列表 https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
这将更新版本号和＆amp;名。
您遇到的不利方面是您无法再使用您尝试使用的自动递增数字。您需要自己提供版本号，然后使用上面的输出将其传回。
然而，您可以使用自动递增让构建系统创建版本号，然后将其写入您需要的位置。
https://www.visualstudio.com/en-us/docs/build/scripts/
如果您正在使用Git，您可以使用GitVersion在构建期间为您创建语义或自动递增数字。或者您可以使用文件明确指定数字。