技术：
Proget – Nuget 包管理服务器
TFS – 内部部署 2017 更新 1
问题： 从 TFS 版本重新发布构建时，要重新打包已经进入我的 Proget 开发提要的 CI Nuget 包，似乎没有办法获得自动语义版本控制。出现的关于在 Nuget 打包程序设置中设置版本的帮助对话框如下。
使用日期和时间 如果您选择“使用日期和时间”，这将生成格式为 XYZ-ci-datetime 的 SemVer 兼容版本，您可以在其中选择 X、Y 和 Z。
使用环境变量 如果您选择“使用环境变量”，您必须选择一个环境变量并确保它包含您要使用的版本号。
使用内部版本号 如果您选择“使用内部版本号”，这将使用内部版本号来为您打包的版本。注意：在 General 下将构建格式设置为 '$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
我希望能够重新发布一个 Nuget 包，该包已经从我在 TFS 中的 CI 构建到我的 Proget 开发提要，再到我的生产 Proget 提要。Microsoft 有一篇关于在持续交付世界中对 NuGet 包进行版本控制的精彩文章。在那篇文章中，他们回避了这样一个事实，即他们正在做类似的事情，但他们没有为如何完成提供任何真正的方向。
问题：
您将如何配置 Nuget 打包程序，以便在创建包时输入构建变量？或者有没有一种方法可以设置主要版本并且每次只增加次要版本？其他人如何处理从开发到生产的软件包推广？
尝试了以下方法：
尝试将 $(Version) 作为构建和发布变量，但它似乎不起作用。包裹被标记日期。此外，这似乎只在 TFS 的构建部分中真正起作用，其中模式窗口包含修改此值的点。
尝试使用日期和时间方法，并将 CI 粘贴到内部版本号中。这几乎正是我们想要减去 CI 定义的结果。因为它会自动插入 CI，所以不适合生产。
将其关闭并从 Nuspec 中提取版本，但这会假设在您的 CI 构建中，您总是在推送最后一个发布版本后将版本号提高到比当前版本多一个。这是因为 nuspec 位于您通过 TFS 发布链重新发布的构建文件中。至少可以说令人困惑。
使用设置为 $(BuildDefinitionName) $(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) 的内部版本号在这里我想要的是 $(Major).$(Minor)。 $（补丁）。尝试使用 1.0.0 版本的 $(Version) $ 会得到一个以 2017.11.3.1 作为输出命名的文件，似乎忽略了 $(Version) 变量。