问维护程序集版本号的最佳实践/指南

EN

AssemblyVersion在.NET中是一个非常重要的东西，微软鼓励的一种理念是让它自动增值，迫使所有依赖于程序集的项目重新编译。如果使用构建服务器，工作正常。除了提防拿着剑的人之外，这从来都不是一件错误的事情。

另一个，与其实际意义密切相关的是，这个数字代表了程序集的公共接口的版本控制。换句话说，只有在更改公共接口或类时才会更改它。因为只有这样的更改才需要重新编译程序集的客户端。这需要手动完成，但是构建系统不够聪明，无法自动检测到这样的更改。

您可以进一步扩展此方法，只在程序集部署到您无法访问的机器上时增加版本。这是微软使用的方法，他们的.NET程序集版本号很少改变。主要是因为它给他们的顾客带来了相当大的痛苦。

所以微软所宣扬的并不是它所实践的。然而，它的构建过程和版本控制是无与伦比的，他们甚至有一个专门的软件工程师来监视流程。WaitHandle.WaitOne(int)重载(特别是造成相当大的痛苦 )的效果不太好。修正了在.NET 4.0中使用了一种非常不同的方法，但这有点超出了范围。

这取决于您和您对如何控制构建过程和发布周期以做出自己的选择的信心。除此之外，自动递增AssemblyFileVersion是非常合适的.然而，这是不支持的不便之处。

您可以使用版本号的生成部分进行自动增量。

[assembly: AssemblyVersion("1.0.*")]

在您的环境中，测试版本是具有构建版本!= 0的版本。在发布时，增加次要部分并将构建部分设置为0，这是标识已释放程序集的方式。

如果你在GAC中安装你的组件，你的GAC会随着时间的推移而被很多不同的版本淹没，所以请记住这一点。但是如果您只在本地使用dll，我认为这是一个很好的实践。

添加到布朗姆斯基回答中，我想指出的是，在semver.org的语义版本2.0标准之后，Major.Minor.Build.Revision将是非法的，因为在增加一个数字之后，所有向右的常规值都必须重置为零。

遵循该标准的一个更好的方法是使用Major.Minor+Build.Revision。这显然不适合在AssemblyVersionAttribute中使用，但是可以使用自定义属性或静态类。

TeamCity中的Semver应该可以使用.对于具有git流的git(特别是在.NET世界中)，我发现GitVersion是有用的。