我的构建号格式指定为：
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
这将以“BuildDefinitionName_2015.11.11.1”
的格式创建构建号码修订版似乎是当天构建运行的次数。
我希望能够在进一步的构建步骤中使用此值。
例如，我正在使用nuget packager步骤创建一个nuget包，并使用“使用内部版本编号来对软件包进行版本化”选项
这会创建类似于“PackageName.2015.11.11.1.nupkg”
的包然后我想使用nuget发布者构建步骤来发布它，但问题是随着时间的推移，你会在包文件夹中获得多个包，而nuget发布者步骤会使用模式来匹配要发布的包。
即
如果没有明确要发布的文件，发布者步骤将发布所有这些文件。
我不想要这个，我只是希望它发布与当前版本号匹配的文件。
所以我希望能够在模式中设置内部版本号部分。
即PackageName.$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r).nupkg
但似乎这些变量在搜索路径中没有被替换，而是作为文字匹配而来。
似乎很奇怪，在nuget包中，它为您提供了按内部版本号创建包的选项，但是后来不允许您在nuget发布构建步骤中匹配它。
答案 0 :(得分：3)
Nuget Packager步骤使用PowerShell脚本获取内部版本号。源代码位于：https://github.com/Microsoft/vso-agent-tasks/blob/84746169f19b7c3e3f67c0efa1a546c4107055fa/Tasks/NugetPackager/NuGetPackager.ps1
如果您确实要将内部版本号转移到Nuget Publish，则可以在构建过程中添加PowerShell步骤以获取构建版本号。有关详细信息，请参阅源代码中的构建版本相关代码。
在PowerShell脚本的最后，添加代码：
Write-Host "##vso[task.setvariable variable=bversion;]$NewVersion"
此代码创建一个填充了版本号的变量“bversion”。然后，您可以在Nuget Publish步骤中使用变量$（bversion）。
答案 1 :(得分：0)
我建议在每个版本中对源代码进行干净的检查，这将解决在后续版本中包含旧包文件的问题。
否则，$（build.buildnumber）变量包含内部版本号的扩展值，但只要您在内部版本号中另外包含$（BuildDefinitionName），您就不会能够将它用作文件名。有关可用预定义变量的列表，请参阅here。