我有一些存储在 TFS 下的嵌入式 C 软件，并且还有一个相应的 TFS 构建定义，可以成功检查代码并使用相关编译器构建它。所以要明确一点，虽然这是 TFS，但我不是在构建 .NET 应用程序。
现在我已经构建工作，我正在尝试提供应该链接到构建过程的整体软件版本控制支持。我目前的目标如下：
正在构建的源代码有一个头文件，其中包含三个变量的#defines，主要版本、次要版本和内部版本号。然后，此头文件用于在编译时将版本号烘焙到软件中。这个概念是作为开发的一部分，开发人员只负责更新主要和次要版本号。内部版本号在源代码中始终保持为 0，并且不应由开发人员修改。
在开发人员在他们自己的机器上本地生成构建的情况下，主要和次要版本将按照代码中的定义进行设置，但构建号将保持为 0，这表明构建不受控制。但是，对于服务器上的正式版本，我希望 TFS 自动增加版本号，以便指定相同主要和次要版本的后续版本导致版本号增加，以提供整体唯一的版本描述符。
在做了一些阅读之后，我具体看到这项工作的方式是将 TFS 内部版本号格式定义为如下所示： $MajorVersion.$MinorVersion.$(Rev:.rr) 其中 MajorVersion 和 MinorVersion 是我定义为的变量构建过程的一部分。
我意识到修订版根据整个内部版本号格式保持唯一性。因此，我认为在尝试评估修订版和更广泛的内部版本号之前，从源代码中提取主要版本和次要版本并填充两个构建变量是至关重要的。我创建了一个 Powershell 脚本，使用正则表达式从头文件中提取主要和次要版本，然后在脚本中设置变量。
现在终于解决问题了。看来我的方法有缺陷。一旦我将构建排队，就会立即评估 TFS 构建号，似乎是为排队的构建命名。在这个阶段，我无法运行我的脚本来提取主要和次要版本，因此也得到了错误的修订号。因此，根据我之前提到的内部版本号格式，我最终会得到一个内部版本号和结果名称，例如“..01”或“0.0.01”，具体取决于我是否在构建定义中初始化了主要变量和次要变量。
那么，任何人都可以看到一种方法，我可以将 TFS 内部版本号的评估推迟到我有机会通过 Powershell 构建步骤从源代码读取我的主要和次要版本之后？如果我能做到这一点，应该根据真正的主要和次要版本正确计算修订。然后，我将使用另一个脚本在我的头文件中仅设置内部版本号#define 以匹配 TFS 内部版本号中的修订。此外，由于 TFS 似乎使用内部版本号作为排队构建的名称，我不确定如何处理这个问题，因为我不知道构建排队时的最终 TFS 内部版本号。在构建过程中可以修改名称吗？
请帮忙。我认为我的想法相当简单，但我正在努力使用其他非常好的 TFS 2015 构建系统来实现它。