我正在寻找关于如何管理.NET程序集的三个不同程序集版本号的指针，建议甚至口述。产品版本是最简单的，因为这似乎通常由业务决定。然后，文件版本似乎是用于部署之间的版本控制，其中实际的程序集版本仅在发货时使用。
现在我只是想找一个简单的方法来标记组件的测试和维护版本，而这些版本都没有依赖，因此我正在考虑在文件版本上自动递增构建版本和版本号，并且最终版本，将当前文件版本复制到程序集版本。该产品正在生产中使用，但仍在开发中 - 您知道 - 其中一家小公司，没有变更控制基础设施的情况。
答案 0 :(得分：204)
答案 1 :(得分：57)
[AssemblyVersion]在.NET中是一个非常重要的事情。 Microsoft鼓励的一个理念是让它自动增加，强制重新编译依赖于程序集的所有项目。如果您使用构建服务器，则可以正常工作。它绝不是错误的事情，但要小心携带剑的人。
另一个与其实际含义更密切相关的是，该数字代表了程序集公共接口的版本控制。换句话说，只有在更改公共接口或类时才更改它。由于只有这样的更改才需要重新编译程序集的客户端。这需要手动完成，但构建系统不够智能，无法自动检测到这种变化。
您可以进一步扩展此方法，只需在将程序集部署到您无法访问的计算机上时增加版本。这是Microsoft使用的方法，它们的.NET程序集版本号很少更改。主要是因为它给客户带来了相当大的痛苦。
所以微软所宣扬的不是它的实践。然而，它的构建过程和版本控制是无与伦比的，甚至还有一个专门的软件工程师来监控这个过程。没有那么好用，WaitHandle.WaitOne（int）重载特别是caused a fair amount of pain。在.NET 4.0中修复了一种非常不同的方法，但这有点超出了范围。
这取决于您和您对如何控制构建过程和发布周期以自行选择的信心。除此之外，自动递增[AssemblyFileVersion]是非常合适的。然而，这是不支持的不便。
答案 2 :(得分：11)
您可以使用版本号的Build部分进行自动增量。
[assembly: AssemblyVersion("1.0.*")]
在您的环境中，测试版本是具有构建版本的版本！= 0.在发布时，您将增加次要部分并将构建部分设置为0，这是您识别已发布的程序集的方式。
如果您在GAC中安装程序集，您的GAC会随着时间的推移而充斥着许多不同的版本，因此请记住这一点。但是如果你只在本地使用dll，我认为这是一个很好的做法。
答案 3 :(得分：9)
添加到Bronumskis answer，我想指出，在semver.org的语义版本2.0标准之后，Major.Minor.Build.Revision将是非法的，因为规则在增加一个数字后，所有常规右边的值必须重置为零。
遵循标准的更好方法是使用Major.Minor+Build.Revision。这显然不适用于AssemblyVersionAttribute，但可以使用自定义属性或静态类。
TeamCity中的Semver应该可以使用Meta-runner Power Pack。对于使用git-flow的git（特别是在.NET世界中），我发现GitVersion很有帮助。
答案 4 :(得分：1)
对于版本控制程序集没有严格的规则，所以请随意尝试哪些适合您，但我建议您使用4部分方法，因为您将拥有您想要的灵活性在将来做一些改变。
... 例如：1.0.0。*
保留 - 这会增加额外的灵活性，因为您希望将来进行任何更改。但作为默认值，请将其保留为0。
另外，请考虑使用强密钥签署程序集。如果您在GAC中注册了多个版本的程序集，这将解决程序集冲突问题。 MSDN Link