我想知道如何自动化使用当前TeamCity构建服务器构建的.Net / NuGet项目的版本控制。
我现在做的是：我的C＃解决方案在存储库中检查，我有（并希望保留）两个构建作业： stable 和 experimental 。 master分支上的提交会触发稳定构建，所有功能分支上的提交都会触发实验构建。我使用特殊分支master-dev来累积更改，然后我最终将其合并回主服务器以触发下一个稳定版本。
在版本化项目时，我使用以下版本控制方案：«major».«minor».«buildnum»用于稳定版本，«major».«minor».«buildnum»-Experimental用于实验版本。到目前为止，我在系统变量中设置主要版本和次要版本，使用“AssemblyInfo修补程序”构建功能相应地修补我的AssemblyInfo.cs，并将版本作为参数传递给“NuGet pack”构建步骤。这样做，但它有两个恼人的缺点：
两个作业之间没有同步，实验的增长速度要快得多。每当我发布稳定版本时，我基本上都必须将实验版本的所有用户“降级”到稳定版本，因为前者严格更高。
每次稳定发布后，必须在TeamCity中更新版本号。
为了简化我的工作流程，如果我能够a）自动同步两个作业之间的构建号，并且b）在每次“稳定”构建之后自动更新次要版本，那将是非常棒的。最理想的是，我还想将版本号存储在存储库中（而不是维护TeamCity变量）。与Maven部署/版本插件非常相似，“稳定”构建作业需要更新版本并将更改推送到存储库（不会触发新构建）。
我既没有找到能够解决这些烦恼的工具（也许有可能为此目的开发一个小型的TeamCity插件），也没有找到任何关于如何以不同方式解决这些版本问题的真正建议......我错过了明显的吗？其他人在TeamCity中简化/自动化.Net / NuGet版本的最佳实践有哪些？
感谢任何指针！
答案 0 :(得分：0)
我喜欢使用的一种模式是使用powershell脚本在构建之前更新SolutionInfo或AssemblyInfo文件。然后在构建完成时提交更改的文件。
在更新文件，更新文件之前更改该模式以获取最新版本并不难，然后立即提交更改以帮助最大限度地降低由并行构建阻止版本号的任何风险。
我看到有人说你不应该让构建服务器提交到源代码，但我不同意。在源代码中拥有版本号意味着您需要的所有内容都在源代码中。
答案 1 :(得分：0)
您可以寻找什么，但是您需要编写一些代码才能实现目标。
我使用的模式类似于扭曲的mentat，但没有将版本号提交回版本控制。
根据项目，我要么有一个C＃程序，批处理脚本或者PowerShell脚本，我用它来更新所有程序集和二进制文件的版本号。我将这些脚本保存在项目的修订控制中，该文件位于名为factory的文件夹中。通常名称为uvn.extension（示例为unv.ps1），其中uvn代表更新版本号。
通常我使用的版本格式是<major>.<minor>.<patch>.<revision>，其中revision是最后一次提交编号。但是，在修订控制中，<revision>数字始终设置为零。
当新版本的时间临近时，我将手动运行uvn.ps1，新版本将<revision>数字设置为零，并将更新文件提交给版本控制。
对于TeamCity，第一个构建步骤是运行uvn脚本。对于TC构建步骤，确定要使用的版本greps用于源中找到的当前<major>.<minor>.<patch>版本。对于<revision>数字，它被设置为使用它正在构建的提交的修订号。下一个构建步骤负责编译，打包和测试。我不会将更改的代码提交回版本控制。